HEP icon indicating copy to clipboard operation
HEP copied to clipboard

HEP Max message length

Open kinsu opened this issue 3 years ago • 14 comments

Assuming that we want to use HEP to encapsulate an HTTP2 message (frame), max message size defined in HEP header (currently 65535) can be restrictive. i guess header change means new HEP version ?

kinsu avatar Mar 03 '23 10:03 kinsu

good question :-) i think yes - otherwise you have to implement fragments. But can you please describe the scenario for such big duplication ? Normay we use payload protocols for miroring, but not entire transport frame.

adubovikov avatar Mar 03 '23 10:03 adubovikov

thanks for the fast reply, yes thats true but payload (e.g. HTTP2 body in Captured packet payload chunck) can grow and exceed the 65K which would cause the whole HEP message to overflow too or i am missing something ?

kinsu avatar Mar 03 '23 11:03 kinsu

honestly, and maybe I wrong, we don't expect SIGNALING protocols size over 65K. As I mentioned before, to duplicate HTTP2 Frames which size is over 65K, by using HEP is absolutely not efficient. First too much overhead (memcopy, serialization, deserialization), second too much traffic, third - too huge receiver buffer. IMHO better duplicate and store directly from network stack the packets as they arrived. But again, it's IMHO :-)

adubovikov avatar Mar 03 '23 11:03 adubovikov

valid point about the overhead and NW packets but the issue is that with HTTP2 comes the encryption so duplication/mirroring on this level is tricky.

would you consider to increace the max size in a followup version ?

kinsu avatar Mar 03 '23 12:03 kinsu

@kinsu This is interesting. Could you expand on your usecase/project where this would be required?

lmangani avatar Mar 03 '23 12:03 lmangani

The intention is to use HEP to encapsulate HTTP2 for traffic monitoring. And in this case as can be seen in 3GPP 29.510 NFDiscovery responce includes an Array of NFProfile objects which can grow quite big (eg MB).

kinsu avatar Mar 21 '23 11:03 kinsu

we can start working on HEP4 and increase the length field to 32 bytes (IMHO ~4G payload will be enougth) ;-) also you can use Protobuf and custom schema to send data to heplify-server - just another way

adubovikov avatar Mar 21 '23 11:03 adubovikov

The beauty of HEP3 is its extensibility. We will shortly propose a backwards compatible extension for discussion.

lmangani avatar Mar 21 '23 12:03 lmangani

thank you i ll be waiting for the proposal- especially the backwards compatibility aspect

kinsu avatar Mar 21 '23 13:03 kinsu

By the way, are there any other changes that you have in mind as part of the HEP4 or just the field size that we were discussing above ? Also, do you have any (obviously rought) timeline on when the proposal will be available ?

thanks again for the help!

kinsu avatar Mar 30 '23 14:03 kinsu

it probably take a week - we are now busy with cloud launch. Thank you!

adubovikov avatar Mar 30 '23 19:03 adubovikov

I personally doubt this change alone would be worth releasing HEP4....

lmangani avatar Mar 30 '23 19:03 lmangani

it probably take a week - we are now busy with cloud launch. Thank you!

thanks !

I personally doubt this change alone would be worth releasing HEP4....

are there any other items that are requested/planned for HEP4 ?

kinsu avatar Apr 04 '23 09:04 kinsu

Hi ! are there any news on this topic ? thx

kinsu avatar Apr 24 '23 15:04 kinsu