Q:

Difference between server side and client side high and low write watermarks options in netty 4

Netty best practices (slides w/ video) by Norman Maurer introduces the WRITE_BUFFER_HIGH_WATER_MARK and WRITE_BUFFER_LOW_WATER_MARK option. It also gives and example:
//Server
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.childOption(ChannelOption.WRITE_BUFFER_HIGH_WATER_MARK, 32 * 1024);
bootstrap.childOption(ChannelOption.WRITE_BUFFER_LOW_WATER_MARK, 8 * 1024);

//Client
Bootstrap bootstrap = new Bootstrap();
bootstrap.option(ChannelOption.WRITE_BUFFER_HIGH_WATER_MARK, 32 * 1024);
bootstrap.option(ChannelOption.WRITE_BUFFER_LOW_WATER_MARK, 8 * 1024);

There is also another discussion on this topic on StackOverflow. But I'm still not sure about some details.
Do the high and low write watermarks options set in client side control the behaviour of the queue written from client to server, and the server side options control the behaviour of the queue written from server to client? 
Which means if the server side high watermarks options is set, then the server side channel which writes data to client becomes not writable when the client receives slowly and the previously written data has filled the queue? And vice versa for client side options.
BTW, I'm using netty 4.1.0CR.

A:

Which means if the server side high watermarks options is set, then
  the server side channel which writes data to client becomes not
  writable when the client receives slowly and the previously written
  data has filled the queue? And vice versa for client side options.

Once the data in the channel reaches high watermark the channel.isWritable method starts returning false until the channel reaches low watermark again. 
But then, if we don't check/ignore channel.isWritable status and keep writing to channel even after it reaches high watermark, it could ultimately result in OOM error as indicated in the two previous slides. 
UPDATE

Do the high and low write watermarks options set in client side
  control the behaviour of the queue written from client to server, and
  the server side options control the behaviour of the queue written
  from server to client?

That is absolutely true.

