* increase in size for struct request_sock tolerable ?
@ 2010-03-03 9:35 Sébastien Barré
0 siblings, 0 replies; only message in thread
From: Sébastien Barré @ 2010-03-03 9:35 UTC (permalink / raw)
To: netdev; +Cc: alan.p.smith
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2010-03-03 9:46 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-03 9:35 increase in size for struct request_sock tolerable ? Sébastien Barré
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox