Re: [MBONED] [pim] [Msr6] MSR6 BOF 3rd Issue Category: More details are requested about the large scale use cases, including issue 8-11

[Toerless Eckert <[e-mail]>]

On Tue, Oct 25, 2022 at 02:10:22PM -0700, Dino Farinacci wrote:
> > I fully agree with the variable length, and i am still promoting this
> > idea as a further evolution of the IPv6 base header. But that does not neglect
> > the fact that we needed to also support long addresses to build the Internet of today.
> 
> Variable length addresses allows for longer addresses. And guess what, short ones too LOL.

Indeed. Given how successful the concept of embedding multicast into IP was in 1989 and
even more so later with IPv6 (RFC3306 and RFC3956) i am pretty sure that BIER would have
ended up putting the bitstring into IPv6 destination addresses if those could have gone
to eg: at least 512 bitlength or the like.

Remember that Cisco/Pierre-Pfister was making exactly that proposal in BIER, and i think many of
us (including me) liked that very much as the most obvious IPv6 method for BIER except
that the at most 80 bits where felt to be too short. Unfortunately BIER has since then
moved on to say that there is no space for headers other than RFC8296, which is a
bit the core of the problem we're overall discussing here. for IPv6.

*sigh*

> I view existing data-planes that put control stuff in the header at entries <= 4. Meaning labels or entries in ann SRH. For MPLS, that is small, for SR its large. But its still <= 4 things.
> 
> You are trying to support >= 100 and even 2 orders of magnitude more LOL!

Well, its not only number of items to act on, but the size and complexity of any
individual item to act on. Arguably, looking up an IPv6 address is more expensive
than looking up an IPv4 address. And its easily quantified by maximum packet
throughput numbers for one platform comparing IPv4/IPv6. and given the longer prefixes
that is often factor 2 more expensive.

SRH is actually interesting in as far as that the processing cost for the
CPU does not go up with length. Aka: doubling the size of the segment list
is not the same as doubling the length of an address. It is primarily the cost
of making up to N (256/512/...) bytes of the header accessible to forwarding
plane operations. Same concept wrt. CPU as MPLS, just higher cost because of
128 vs. 32 bits "addresses/SIDs".

Same with multicast: 
Lookup of BIER/BIER-TE bitstrings is proportionally expensive to their size,
like the lengths of prefixes in unicast addresses. Because routers always need
to examine and act on the whole bitstring.
With Recursive Bitstring Structures (RBS, draft-eckert-msr6-rbs for MSR6 and
draft-eckert-rbs independent of encap BIER/MSR6) we avoid that problem and turn
it into the same performance as SRH/MPLS: each router only need to look at small
bitstrings - as many bits as router has interfaces. 

> > Loss probability primarily comes with size of tree such as number of hops where
> > BER can happen. Luckily it seems that the faster we make optical links, the better we can
> > deal with that (energy consumption of transceivers doing all this FEC computations is not
> > even going up linearly with speed).
> 
> Umm, don't build an architecture where you have something else fix its shortcomings. Loss comes from many-to-1 output queues in routers. Its called congestion and we live with it every day. And it is relatively random so you can measure a probability to it.

Ok. didn't think you meant congestion loss, you didn't say so.

It's not a problem to build queues where the counted  qsize
of packets is only payload, not network header. But agreed on
queuing memory cost. Just well worth the price of admission IMHO.

Cheers
    Toerless

> 
> Dino
> 

-- 
---
[e-mail]