Re: [tcpm] [EXTERNAL] Re: Linux TCP Stack and Zero Window Probe

[Neal Cardwell <[e-mail]>]

On Fri, Nov 23, 2018 at 12:33 AM Varadarajan, Kiruthika
<[e-mail]> wrote:
>
> Hi Neal,
>  But RFC spec https://tools.ietf.org/html/rfc793#section-3.7  says after TCP-Zero Window from client, server must send
>  TCP Zero Window Probe,

>From the packet trace it seems like that is what happened.

> Hence in tcp_write_wakeup, tcp_xmit_probe_skb expect mib to be LINUX_MIB_TCPWINPROBE

Yes, indeed. Do you have snapshots of the SNMP counters from the
machine before and after that trace, to show that the wrong counter
was incremented?

>   Are we not violating the spec?

The on-the-wire behavior of the server looks fine to me.

However, if we are looking for spec violations, it looks like the
client is violating the spec by retracting the right edge of the
receive window (from "ack 936571642 win 65535" to "ack 936571643 win
0").

best,
neal

>
> Thanks & Regards
> Kiruthika
>
>
> -----Original Message-----
> From: Neal Cardwell <[e-mail]>
> Sent: Thursday, November 22, 2018 11:52 PM
> To: Varadarajan, Kiruthika <[e-mail]>
> Cc: [e-mail]; John Heffner <[e-mail]>
> Subject: [EXTERNAL] Re: [tcpm] Linux TCP Stack and Zero Window Probe
>
> Hi,
>
> This is expected. Linux TCP uses the same code to generate keepalive probes and zero window probes. (Note that the comment for
> tcp_write_wakeup() is "Initiate keepalive or window probe from timer"). So, on the wire and divorced from context, the two kinds of packets can look the same.
>
> Given the context in your trace, with the receiver just having advertised a receive window of 0 bytes, and with the probes starting in the range of a plausible RTO, and exponentially backing off, those look like zero window probes to me.
>
> best,
> neal
>
> ps: this is a condensed version of the trace, with tcpdump -ttt relative timestamps:
>
> 00:00:00.025099 cli > srv: S 3878781099:3878781099(0) win 65535
> 00:00:00.000506 srv > cli: S. 936571641:936571641(0) ack 3878781100 win 29200 <mss 1460>
> 00:00:00.012473 cli > srv: . 3878781100:3878781100(0) ack 936571642 win 65535
> 00:00:01.003173 srv > cli: P. 936571642:936571643(1) ack 3878781100 win 29200
> 00:00:00.013407 cli > srv: . 3878781100:3878781100(0) ack 936571643 win 0
> 00:00:01.208250 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200
> 00:00:00.431995 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200
> 00:00:00.887970 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200
> 00:00:01.728002 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200
>
> On Wed, Nov 21, 2018 at 1:21 PM Varadarajan, Kiruthika <[e-mail]> wrote:
> >
> > Hi Team,
> >
> > I have a question in Zero Window Probe in TCP.
> >
> > If the client sends Zero Window, according to RFC spec is it mandatory for the Linux TCP stack to send Zero Window Probe.
> >
> > In my stack I am not getting Zero Window Probe instead I am getting Keep Alive.
> >
> > I have attached my wireshark traces. Can you please confirm if this is the expected behavior from TCP stack.
> >
> >
> >
> > Thanks & Regards
> >
> > Kiruthika
> >
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://clicktime.symantec.com/a/1/5s9OgpuGADG4-wNayiKCDaOjp4t8xEdNzIn
> > 2m0gIhbI=?d=qwuG2lD1HGyTkT6ITNv2T-IZTsKEDQELHhOKuO35Yk6DwAqCw1_maSu9uJ
> > i0SJ5OoL5hRXxKfFMVVdPrpH7NqZoiA2iC4_sW9S5DS8iXPcFtveFaRZZFaeZljCDHcVjl
> > xGLuxkxQiLkfINXKkyvEqaSjSfeVtRsTfQhI132DIcQK0oBZZDjznRwodB8-1z5IYJc117
> > 0EKN7vW6nIs6Ug8yblmgjnqohW8wj-qHIe60MRPZCTjCKuX75_GBdSeDqbClpyP2Uaczeg
> > V_iBHcfXZ169q2w-y4tw5aTb7k8GZGhL5GXn0fUoJI04PoL6ORc8y9k_WIifEzO2n3Cj5o
> > 6WglDXjpCXY8kutM0uPkzUW3wllvo3A2eUDgh2PcC28FpG8y2DIqRdWzm3iUZe8IWZsF-n
> > fmqH82BLc3gyCOk%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2
> > Ftcpm