freeswan/klips/doc/klipsNGreq/requirements/007/requirement007.tex

   1 \subsection{007: why do equalizing schedulers not play well with tunnels?}
   2
   3 \subsubsection{007: Definition of requirement }
   4
   5 linux/net/sched/sch\_teql.c says:
   6
   7 \begin{verbatim}
   8     1. Slave devices MUST be active devices, i.e., they must raise the tbusy
   9        signal and generate EOI events. If you want to equalize virtual devices
  10        like tunnels, use a normal eql device.
  11 \end{verbatim}
  12
  13 A normal ``eql'' device ({\tt linux/drivers/net/eql.c}) simply does a simple
  14 form of round-robin scheduling among devices. It can round robin among
  15 devices of equal weight.
  16
  17 The teql scheduling device uses the scheduling system's back pressure (the
  18 {\tt dev->tbusy} flag) to give each device as much as it wishes.
  19
  20 \subsubsection{007: response}
  21
  22 The KLIPS1 {\tt ipsecX} devices are never busy. They therefore can not be
  23 equalized using this scheduler.
  24
  25 The virtual devices could use the {\tt tbusy} mechanism. To be able to
  26 do this, the {\tt MAST} device will have to be given a clear amount of
  27 resources on a per-virtual device basis. As the limit to throughput will be
  28 the lesser of encryption throughput and physical device throughput, once the
  29 buffers are full, the virtual device can raise the {\tt tbusy} flag.
  30
  31 For this to be useful, the paths to the remote host must be
  32 different. Specifically, the outer destination address must in some way be
  33 different. If there are simply two physical ways to get to the same
  34 destination address then standard load-balancing would work once the
  35 {\tt MAST} devices have processed the cleartext.
  36
  37 The use of the {\tt tbusy} feature is not considered to contribute strongly
  38 towards Opportunistic Encryption. The creation of the MAST device is however
  39 critical.
  40
  41
  42