increase in size for struct request_sock tolerable ?

["Sébastien Barré" <sebastien.barre@uclouvain.be>]

Hi,

As part of the development of the MPTCP protocol 
(http://inl.info.ucl.ac.be/mptcp), we are wondering whether it is 
tolerable to extend the length of the struct request_sock. In the 
current version of the protocol 
(http://tools.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt), a 
32bit token is exchanged as TCP options in the SYN and SYN/ACK segments. 
AFAIU, that requires that we store 8 bytes in the request sock for the 
server side, so that it remembers the local and remote tokens until the 
real sock is created.Even worse, since the NULL token is not a reserved 
value, we need to store an additional bit (flag) to know that we 
received that TCP option. Since there are no flags currently stored in 
the request_sock, we need to directly increase the size by 8 additional 
bits.

So with the current protocol design, I arrive to a struct request_sock 
extension of 4 (local token)+4(remote token)+1(1bit flag+7free flags)=9 
bytes.

A minor protocol modification would allow reducing that constraint. 
Basically, we would then differ the token exchange until the real sock 
is created.    The flag would still be needed, though, thus in that case 
we would arrive to 1 byte of extension only for the struct request_sock.

So my question is : Do you think there is a sufficient incentive here to 
adapt our protocol draft ? Or is it tolerable to extend the struct 
request_sock by 9 bytes ?

Thanks in advance !

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre