Re: [mpls] Catalog for MPLS Metadata

[Haoyu Song <[e-mail]>]

In packet header processing, it's not very helpful to know how many headers a packet has upfront, because a parser can easily find them if needed. It's the required buffer depth that directly affect the performance. If a header that needs to be processed per hop is located deeply in the packet, it will be a big hit to the performance. That's exactly why the HBH headers should be put in front of E2E headers. So the order matters.

Some headers may change its size on the path, this is another reason why keeping the offset of each header make the processing more complex (many offsets needs to be updated).

Also, "metadata" is not the right term here. It's actually instruction headers (which may contain metadata of course).

Thanks,
Haoyu

From: Vasilenko Eduard <[e-mail]>
Sent: Monday, April 19, 2021 10:38 AM
To: Haoyu Song <[e-mail]>; mpls <[e-mail]>
Subject: RE: Catalog for MPLS Metadata

In-line

From: Haoyu Song [mailto:[e-mail]]
Sent: Monday, April 19, 2021 7:47 PM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: RE: Catalog for MPLS Metadata

Hi Eduard,

We have thought about adding an extension header summary in the Header of EH, but a detailed list of all the headers and their offsets can make the processing more complex,
[EV] Why?
This table of all headers is not an additional space - It was taken from Metadata. Metadata should have somewhere "type" and "length" anyway.
I am just proposing to concentrate T/L in one place. A small fixed structure is much easy to parse.
because we assume in MPLS, nodes on path may add or remove an EH, which will change the offsets.
[EV] Something added in transit would be probably deleted early than something added at the source. It is like the stack.
I did mention below that it makes sense to add only at the end of Metadata. Then offset calculation would be needed only for added/new metadata.
Instead, we only keep tracks the total number and length of the EHs.
[EV] It would help only to identify TCP. That is good. But could be better.
This info can help to easily access the payload after all the EHs which may be needed for functions like ECMP or DPI.
https://datatracker.ietf.org/doc/draft-song-mpls-extension-header/03/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-mpls-extension-header%2F03%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cfadcaeeea41f439e977e08d90359da63%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637544506744920416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hZkXQDXq5AMs5%2FB5PvRrW%2BfcPCWSUCAd1T3FxKja72M%3D&reserved=0>
[EV] I see that metadata is intermittent with MPLS labels.
It is very wrong because it would break interoperability with old platforms.
Old platforms should see MPLS stack as usual.

Also, listing all the EHs sequentially doesn't exclude the possibility of parallel processing. Many hardware architectures use a frontend parser to parse all the needed headers altogether.
[EV] ASIC's parser block has many ALUs - parallel processing is not possible at parser.
If some headers could be processed in parallel, we can certainly start form here.
Moreover, we categorize the EHs into Hop-by-Hop (HBH) and End-to-End (E2E), and always put HBH in front of E2E to reduce the buffer depth. We think this is enough for our purpose.
[EV] It is exactly what I propose not to do. Do not mandate any order of headers. Do not copy bad practice of IPv6 EH.
In the majority of cases, Metadata would be add as to the stack (last in - first out). Abuse this fact. Catalog of headers would permit this.

Best regards,
Haoyu

From: mpls <[e-mail]<mailto:[e-mail]>> On Behalf Of Vasilenko Eduard
Sent: Sunday, April 18, 2021 11:10 AM
To: mpls <[e-mail]<mailto:[e-mail]>>
Subject: [mpls] Catalog for MPLS Metadata


Hi all,

I did think about it a little more and come up with the below.

I could formalize it in the form of a draft if it would be the interest.


Chain of variable size headers could pose a considerable challenge for hardware pipeline. It needs sequence processing to parse it.
The progress of computing power during the last 15 years is mostly related to multi-core and multi-thread parallel processing. Any future-proof architecture should be friendly for parallel processing.
The challenge in processing IPv6 extension headers and their low adoption is partially attributed to the expensive parsing of the chain of variable length headers.
An additional challenge is the size of the key buffer that is used as the key materials to search in switching and forwarding tables. The cost of processing is linear to the key size. It is important to have the flexibility to ignore or discard some headers to compromise on low-cost platforms. Parsing of all headers in the long chain defeats the goals of a low-cost platform. Hence, parsing simplification and flexibility could help to the problem of restricted key buffer too.
MPLS's new metadata blocks must have some indication of their type and length. It is assumed that MPLS metadata blocks would have separate address space from IANA for block types. It is proposed to collect this information in one centralized table that could be called "Catalog".
There is no need for redundancy of this information in particular metadata blocks. It means that the size of metadata blocks could be reduced respectively. Hence, overall this proposal does not increase the size of the packet. Such an advantage is possible only as of the initial architecture decision.
The Catalog is proposed from a sequence of Type/Offset values. One Type/Offset for every metadata block that would follow Catalog.
The size of the Type is proposed as 1 octet, the size of Offset is proposed as 2 octets. It is the discussion point that should the Offset be the number of Octets or should it be 2, 4, or 8 octets in the metadata block. The former case restricts all metadata headers together by 64k octets that is probably enough. The latter could improve the performance by aligning to the memory unit of a particular platform but it would waste some bandwidth because of the need for padding in metadata blocks.
The positioning of the Catalog is proposed at the bottom of the stack (i.e. between MPLS label with BoS=1 and Data Header) to preserve interoperability with current MPLS implementations.
The Catalog should start from "0000" nibble to avoid packet reordering on old LSRs or a nibble that could be requested from IP protocols space (if possible).
The Catalog should finish with the special type of metadata (255?) which means that the Data Header is started from this Offset.
Hence, overall structure of the catalog would be:
0000
RRRR
Type1
Offset1
Type2
Offset2
...
  ...
TypeN
OffsetN
11111111
Offset of the Data Header

RRRR - reserved nibble.
The offset is calculated from "0000RRRR" octet.
The choice to put offset instead of length in the Catalog is explained by the desire to simplify the read of arbitrary Metadata blocks. The offset would show the start of needed Metadata immediately, the size of the block could be calculated by 1 subtraction (OffsetN++ - OffsetN). Additionally, offset would greatly simplify the search for upper-layer protocols that is much needed for middleboxes, filtering, QoS, and load balancing.
The other possibility was to use the length of the Metadata block. The length would push for the addition of all lengths from the catalog to calculate the arbitrary offset to read.
It makes sense to discuss the rule for not to have the ordering of different types of Metadata blocks. The Catalog does permit to easily find any block. Any new block make sense to add at the end. It permits to avoid the recalculation of Offsets for all previous Metadata blocks.
Fixed-size simplified structure of the Catalog permits to optimize parsing in hardware, arbitrary access to any metadata blocks, and easy search for the next layer offset. All of this could greatly improve the chances for market adoption of MPLS Metadata extensions.



Eduard