Re: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance analysis simulation

[Aijun Wang <[e-mail]>]

I think another benefit of the CGM2/RBS is the flexible/independent
assignment of BP for each adjacency on the BFR/BFER in large network. 
But the drawback is that it can't coexist with the existing BIER forwarding
behavior.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [e-mail] <[e-mail]> On Behalf Of
[e-mail]
Sent: Friday, February 11, 2022 12:40 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance
analysis simulation

Jeff,

It is indeed initially somewhat counterintuitive to think that the CGM2/RBS
bitstring encoding could be more efficient (less copies) than BIER - given
how BIER does not even need to encode the tree but just the leaves. Whereas
CGM2/RBS does encode the tree.

The reason becomes IMHO more obvious, when one considers that BIER needs to
send a separate packet copy even if just ONE BFER in the bitstring needs a
copy. If we have a BSL of 256 bits, it means we encoded 255 "dead-weight"
bits. And if we want to replicate a packet to N% out of a large number of
BFER one can imagine how we get to the points where where the bitstring of
every packet copy will have only a few bits set.

With the compressed tree model, the length of each bitstring of interest is
just the total number of direct adjacencies (BFER or BFR), so the efficiency
of each such bitstring is never as low as 1/256, but maybe just 1/20 - if
the BFR has
20 neighbors (other BFR or BFER). So within a max of 256 bits of "variable
length encoded tree", there is maybe better than 10% of bits to which a copy
is made.

Meaning: I wouldn't want to bet a large amount of money on how exactly the
comparison would play out when we increase the BSL size for both BIER and
CGM2/RBS (as you suggested), because then the efficiency of a BSL=512
bitstring in BIER could be as low as 1/512 if only one bit is set there.
Whereas the percentace "replication efficiency per bit of addressing" in
CGM2/RBS would probably stay the same.

Cheers
    Toerless


On Wed, Feb 09, 2022 at 08:49:26PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> Hi Toerless,
> 
> Not sure if my understanding is correct, but it seems that RBS does not
reduce the number of bits that are needed to encode the tree. Rather, it
increases the number of bits (to encode the recursive structure).
> I agree that it reduces the size of BIFTs, but even current BIER-TE can
reduce the number of copies if you use a longer bitstring?
> 
> Jeffrey
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: BIER <[e-mail]> On Behalf Of [e-mail]
> Sent: Wednesday, February 9, 2022 2:19 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance 
> analysis simulation
> 
> [External Email. Be cautious of content]
> 
> 
> Dear BIER-TE WG:
> 
> Robin did add a section (6.3) describing an initial performance gain
analysis of CGM2/RBS to the github source
(https://urldefense.com/v3/__https://github.com/toerless/bier-cgm2-rbs__;!!N
Et6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP00KEiAWpH592AuDXmrOOJH_bgVzQZyfK9En$
), and i just did a bit of editorial fixup and posted it as -01 of the
draft.
> 
> This actually is the first time i actually like the HTML'ized version of a
draft, because the topology picture is so large it doesn't fit a single
page:
> 
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ecke
> rt-bier-cgm2-rbs-01.html__;!!NEt6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP
> 00KEiAWpH592AuDXmrOOJH_bgVzQaBIgBPC$
> 
> The interesting piece about the comparison is that it is actually
comparing CGM2/RBS to BIER, and not BIER-TE. Because BIER itself should be
requiring less copies than BIER-TE, so the gain of CGM2/RBS over BIER-TE
should be even higher, but the fact alone that you get away with fewer
packet copies to large receiver sets even though the bitstring also needs to
encode the path/tree towards the receivers is really cool.
> 
> Robin, two Q:
> 
> 1. The new text mentions "in our graphs", but the text does not include
any such graphs (yet).
> I guess such a graph would be even worse to convert to ASCII than the
topology.
> Maybe post whatever format you have those results in to github (PDF,
png...) and then we actually may want to see if/how a PDF version of the
draft could include better than just ASCII art. Certainly a good reason to
finally try it out.
> And short term we can just add references to such visuals to the draft.
> 
> 2; Is it correct to assume that the hops through the topology that you
simulated are "just" shortest-path, maybe with some ECMP choice - aka: the
same paths that also BIER would choose given some "default" IGP routing
setup ?
> 
> Cheers
>     Toerless
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
> __;!!NEt6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP00KEiAWpH592AuDXmrOOJH_b
> gVzQZXGUd9P$

--
---
[e-mail]

_______________________________________________
BIER mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bier