Rare project developers

[mc36 <>]

hi.
sorry for the spam but i forgot to tell you a great news:
as some of us was already involved in this thread, i asked vlad if they 
progressed with the crc,
and it seems that yess, they did, we can set the coeff from the control 
plane, hurray:
https://community.intel.com/t5/Intel-Connectivity-Research/Changing-CRC-polynomial-from-the-control-plane/m-p/1323312
regards,
cs



On 10/20/21 05:15, mc36 wrote:
> hi,
>
> thanks for the quick response... i reply topic by topic...
>
> crc:
> just a small footnote that i refactored them again to get back the original 
> speeds...
> the trick there was that it was a static final table that is, it was common 
> for all the
> classes, so it was computed only once... now it's true again...:)
> not that much happened, just the class instantination parameter changed...
>
> sympy:
> after a quick look, it seems to me a huuuge (33mb) symbolic math package...
> but in guess you're only using a small subset of that... at least from the 
> paper,
> my bet is that you only need a class that represents a polynomial, and the
> add, sub, div, mul functions over it (as i shown for ellitic curves during 
> the vc)
> so if that's the case, i would suggest you that simply give me some time and
> let me come up with something that can calculate only these over a poly 
> class...
> if you could shar your current python code could help me to see what you need 
> from sympy...
> i really love doing such things because it refreshes a bit the things i learnt
> during the university classes, and i really like explore and understand 
> things...
> finally, calling out to external libs are always costy because of the
> java-ish overhead that is put by the non-specific libs, and when you
> have an unstable network and you have to recompute frequently then it
> pays off to have everything in hand that you can fully optimize...
> snoopy.vhpc#show platform | include uptime
> uptime: since 2021-10-16 10:00:37, for 3d18h
> snoopy.vhpc#show ipv4 bgp 1955 bestpath | include change
> changes all      15784774
> changes now      37
> snoopy.vhpc#
> it's the worst example i have for the above, it averages to 45 changes / 
> second...
>
> reusing segment routing id from routing protocols:
> so at the moment it's the quickest way i see to fit the need to populate an 
> id->prefix
> and prefix->id table on each node in a network... also keep in mind that 
> freerouter have
> homebrew routing protocols too (http://lsrp.nop.hu/ and 
> http://pvrp.nop.hu/)... so if we
> need a new value somehow, it can arrive in no time to continue 
> experimenting...
> but in a longer run, you should consider ietf rfcs to have specific values 
> just for polka...
>
> thanks,
> cs
>
>
>
>
>
>
>
> On 10/20/21 03:00, Cristina Klippel Dominicini wrote:
> > Hi, Csaba,
> >
> > Thank you very much for this quick response!
> >
> > Yes! The bmv2 implementation explores predefined tables (code below) for 
> > well-known CRC standards and builds the tables for custom polynomials.
> > https://github.com/p4lang/behavioral-model/blob/main/src/bm_sim/crc_tables.h
> > Their solution was inspired by this code that offers a nice introduction to 
> > the CRC calculation: 
> > https://barrgroup.com/Embedded-Systems/How-To/CRC-Calculation-C-Code
> >
> > Your new code seems to fit our requirements perfectly. We will execute some 
> > tests with default parameters to double check.
> >
> > We used CRC16, because the lower the polynomial degree, the better in terms of the bitlength of the routeid. In theory, we could use lower polynomials for small topologies, but 
> > we got some errors with CRC8 in our initial tests in Tofino. We will check if we can use CRC8 in Tofino.
> >
> > Now, we are going to translate our code to provide you with a Java method that performs the routeID computation given the path information (set of the nodeIDs and portIDs). Most 
> > of our polynomial computation uses the galoisfield module of the sympy lib (https://docs.sympy.org/latest/modules/polys/index.html). So, I will check if there is a similar 
> > library in Java. For the nodeid computation, it is just a matter of calculating a list of irreducible polynomials, so it should suffice to have a fixed list of nodeids for the 
> > control plane.
> >
> > Finally, your suggestion to use BGP/IGP for node discovery and reuse the 
> > Segment Routing identifiers seems to be a very elegant solution. We will 
> > study that. Thank you!
> >
> > Best regards,
> > Cristina
> >
> > ________________________________________
> > De: mc36 <>
> > Enviado: terça-feira, 19 de outubro de 2021 17:21
> > Para: Cristina Klippel Dominicini; Cristina Klippel Dominicini; Rafael S. 
> > Guimaraes; Rafael S. Guimarães
> > Cc: 
> > Assunto: Re: custom crc32 library in freerouter
> >
> > hi,
> > sorry for the spam again, but i checked again the polka.patch and found that 
> > maybe you're using crc16?
> > so here we go, i also parameterized it in freertr: 
> > http://src.mchome.nop.hu/src/net/freertr/cry/cryHashCrc16.java
> > with this: 
> > https://github.com/mc36/freeRouter/commit/4958add8b8fc48f1a35199f6e57deeb5dfe768ac
> > i'm never against some good refactoring, afterall... :)
> > also, you really should check the last but one vc, we demoed how 
> > segment-routing traffic engineering can work...
> > that is my intent to reach to that same level with polka, with abusing the 
> > already existing igp's and/or bgp's
> > segrout.index flooding mechanisms... here is the video: 
> > https://www.youtube.com/watch?v=jS6RmHKC4aQ
> > regards,
> > cs
> >
> >
> > On 10/19/21 21:31, mc36 wrote:
> > > hi,
> > > sorry for the spam...
> > > so i played a bit with my crc32 library and found out that i can calculate 
> > > the same values with a single class,
> > > just some parameters need to be passed to it become the "ieee ethernet" or the 
> > > "sctp rfc" version of the crc code...
> > > here is what freertr have now at the moment: 
> > > http://sources.nop.hu/src/net/freertr/cry/cryHashCrc32.java
> > > (my bad, the url was bad in the previous mail...:) and this is what happened 
> > > in the code to reach the single class:
> > > https://github.com/mc36/freeRouter/commit/ca58d4fe39f0cd681d6cd21d3a9a2474e07600a8
> > > if you still need a parameter or anything around the crypto lib, just let me 
> > > know...
> > > but hopefully now, it'll be easy for you to come up with the rest, that is:
> > >   Â - a method to encode the polka.routeid from "List<Integer> nodes"...
> > >   Â - a method to calculate the coefficient (polynominal?) from a single 
> > > node id...
> > > then we can finally have a pure java forwarder and so on, as we discussed in 
> > > the vc...
> > > thanks,
> > > cs
> > >
> > >
> > >
> > > On 10/19/21 17:34, mc36 wrote:
> > > > hi
> > > >
> > > > i've found the crc32_custom magic in bmv2:
> > > >
> > > > behavioral-model-main/src/bm_sim/crc_map.cpp
> > > > behavioral-model-main/src/bm_sim/calculations.cpp
> > > >
> > > > in the crc_map.cpp for crc32c, they uses the same magic as me at 
> > > > http://source.nop.hu/src/net/freertr/cry/cryHashCrc32c.java
> > > > and the table calculation in calculations.cpp seems similar that i do too, 
> > > > but mine works with fixed magic...
> > > >
> > > > but they have no parameter called coefficiet, but the magic called 
> > > > polynomial...
> > > >
> > > > my best guess according to 
> > > > https://en.wikipedia.org/wiki/Cyclic_redundancy_check is that they're the 
> > > > same?
> > > > (but again, it's my bad but i'm a bit noob in these math things, i'm much 
> > > > more a networker and coder guy:)
> > > >
> > > > so if that's the case then i'll create a new crc32 class that needs to be 
> > > > initialized with the poly paramareter...
> > > >
> > > > thanks,
> > > >
> > > > cs
> >
> >
> > ________________________________
> >
> > Esta mensagem (incluindo anexos) contém informação confidencial destinada a um usuário específico e seu conteúdo é protegido por lei. Se você não é o destinatário correto deve 
> > apagar esta mensagem.
> >
> > O emitente desta mensagem é responsável por seu conteúdo e endereçamento.
> > Cabe ao destinatário cuidar quanto ao tratamento adequado. A divulgação, reprodução e/ou distribuição sem a devida autorização ou qualquer outra ação sem conformidade com as 
> > normas internas do Ifes são proibidas e passíveis de sanção disciplinar, cível e criminal.