Allow sending ADD_ADDR IPv6 with port-number if TCP-timestamps are enabled

[cpaasch]

With TCP-timestamps (padded) taking 12 bytes and ADD_ADDR IPv6 + port taking 30 bytes, we are beyond the 40-byte limit for TCP options.

It would be possible to squeeze both options into the header if we first write the ADD_ADDR and then the TCP timestamp without the nops preceding it.

[matttbe]

Some notes from the last meeting:

• TCP timestamps are 12 bytes long if padded
• ADD_ADDR IPv6 + port number is 30 bytes long → 42, too long
• Seems risky to disable TCP Timestamps just for one packet
• Reordering should work: first ADD_ADDR, then TCP Timestamps
• we need to be careful that some middleboxes can be disturbed if options are in a different order (it should not be the case but well) → so best to do that only with this specific packet, not all MPTCP ones

[matttbe]

Note: another way to allow writing more bytes is to wait for TCP EDO support: draft IETF - draft implementation

[pabeni]

Note: another way to allow writing more bytes is to wait for TCP EDO support: draft IETF - draft implementation

That topic has been discussed at netconf, EDO has many disadvantages/drawbacks (among them requires disabling GRO). It will not land upstream anytime soon (if ever)

[matttbe]

From the meeting we had last week:

• Likely two solutions:
  • disable the TS on this specific packet:
    • some middleboxes could drop the packet (not good but OK) or reject the connection (arf)
    • the TCP stack and ConnTrack should be OK with that
    • should be easier to do that
  • re-order TS:
    • also here, some middleboxes could drop the packet / reject it but OK for Linux
    • we save 2B (padding) while keeping all info
• Or always re-order?
  • why not always putting the TS after: could we not avoid a double padding (4B) in all MPTCP packets with data?
  • but maybe more risks to hit middleboxes not finding the TS at a "fixed spot"?
  • or maybe OK if it is controlled by a sysctl knob?