Re: [lp-wan] SCHC over PPP comments

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Ana : )

> Your document is the only way to give an IETF solution for layer_2 links. The number of bits a Rule ID must have depended on different factors. Why is the size of RuleID not of variable length?

That was to save the bits that would indicate the length : )
Now we could use the first bits to indicate the length, but then how many bits to express the length and in which unit is the length express (bits, bytes?).

> The solution may take into account other links where bandwidth is a real problem. The RuleID must have a minimal size but not of 16 bits; It is too big! And a variable-length will avoid using PAD after compression.

Even vs.old SLIP the overall win of using SCHC with 2 bytes is worth it. Now look at the overall PPP header. If you can not dedicate 2 bytes for SCHC, PPP is probably not for you either, think LoRa or Sigfox

> Why are you reserving two MSB bits? To do what?

The history of 6LoWPAN tells us that we always need more space. For now we reserve 00xx and 1111. We already discussed that we could send well known control.

> In version 1 of your document, there is no fragmentation indication, but during your presentation, fragmentation uses a RuleID of 4 bits. I saw your presentation again. I understand when using fragmentation, the 16bits of RuleID in the PPP header will represent the fragmentation header 1111-DTag-N... and 1111 indicates NO_ACK, isn't?

Were you looking at the INTAREA version, https://tools.ietf.org/html/draft-thubert-intarea-schc-over-ppp-01 ?
Otherwise yes, 1111 is NO ACK so we can use other 11xx for other ack mode if they are needed in the future.
01xx and 10xx would also be reserved for the future.

> I understand that this configuration may function for high bandwidth links. Nevertheless, I believe that the best way to define the Rule ID size is to avoid giving fixed sizes.

Then again PPP is not for MTUs of a dozen bytes. Open to suggestions for how to express length if needed: See my question earlier.

Take care,

Pascal




From: Ana Minaburo <[e-mail]>
Sent: mardi 22 septembre 2020 22:43
To: Pascal Thubert (pthubert) <[e-mail]>; lp-wan <[e-mail]>
Cc: Eric Vyncke (evyncke) <[e-mail]>
Subject: SCHC over PPP comments

Dear Pascal,

Some points of discussion that could be interesting for the new format of the Rule ID you are proposing.

Your document is the only way to give an IETF solution for layer_2 links. The number of bits a Rule ID must have depended on different factors. Why is the size of RuleID not of variable length?

The solution may take into account other links where bandwidth is a real problem. The RuleID must have a minimal size but not of 16 bits; It is too big! And a variable-length will avoid using PAD after compression.

Why are you reserving two MSB bits? To do what?

In version 1 of your document, there is no fragmentation indication, but during your presentation, fragmentation uses a RuleID of 4 bits. I saw your presentation again. I understand when using fragmentation, the 16bits of RuleID in the PPP header will represent the fragmentation header 1111-DTag-N... and 1111 indicates NO_ACK, isn't?

I understand that this configuration may function for high bandwidth links. Nevertheless, I believe that the best way to define the Rule ID size is to avoid giving fixed sizes.

Ana