{"action":"created","issue":{"url":"https://api.github.com/repos/mirage/mirage-tcpip/issues/140","labels_url":"https://api.github.com/repos/mirage/mirage-tcpip/issues/140/labels{/name}","comments_url":"https://api.github.com/repos/mirage/mirage-tcpip/issues/140/comments","events_url":"https://api.github.com/repos/mirage/mirage-tcpip/issues/140/events","html_url":"https://github.com/mirage/mirage-tcpip/issues/140","id":80128247,"number":140,"title":"Retransmissions and duplicate acks","user":{"login":"talex5","id":554131,"avatar_url":"https://avatars.githubusercontent.com/u/554131?v=3","gravatar_id":"","url":"https://api.github.com/users/talex5","html_url":"https://github.com/talex5","followers_url":"https://api.github.com/users/talex5/followers","following_url":"https://api.github.com/users/talex5/following{/other_user}","gists_url":"https://api.github.com/users/talex5/gists{/gist_id}","starred_url":"https://api.github.com/users/talex5/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/talex5/subscriptions","organizations_url":"https://api.github.com/users/talex5/orgs","repos_url":"https://api.github.com/users/talex5/repos","events_url":"https://api.github.com/users/talex5/events{/privacy}","received_events_url":"https://api.github.com/users/talex5/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-05-24T11:06:08Z","updated_at":"2015-06-03T18:25:39Z","closed_at":null,"body":"Testing from my cubieboard2, I'm getting a lot of TCP retransmissions and duplicate acks. It happens frequently when using TLS, but I have seen it even just streaming plain TCP (without even HTTP), though it took many tries before I saw it.\r\n\r\nHere are some pcap files in case someone more knowledgable wants to take a look:\r\n\r\n- http://test.roscidus.com/static/cuekeeper-tls-fail-fast.pcap : a trace showing Mirage ignoring the first client hello, then sending a server hello on the retransmit, getting an ack for it and immediately sending two duplicate acks, followed by lots more strangeness later. The client is Firefox trying to load CueKeeper.\r\n\r\n- http://test.roscidus.com/static/plain-tcp.pcap : a trace from mirage-skeleton/network modified to send a fixed buffer over and over again after reading the client data. There's a dup ack near the start, then things are good for a while, then at 0.9083s it suddenly sends a TCP segment with a much higher sequence number and things go badly for a while, until it eventually recovers at around 4s (I removed the rest of the trace after that). The client is a simple `nc` invocation.\r\n\r\nCould someone who understands TCP and/or Mirage's implementation suggest what could be going on here?"},"comment":{"url":"https://api.github.com/repos/mirage/mirage-tcpip/issues/comments/108560783","html_url":"https://github.com/mirage/mirage-tcpip/issues/140#issuecomment-108560783","issue_url":"https://api.github.com/repos/mirage/mirage-tcpip/issues/140","id":108560783,"user":{"login":"talex5","id":554131,"avatar_url":"https://avatars.githubusercontent.com/u/554131?v=3","gravatar_id":"","url":"https://api.github.com/users/talex5","html_url":"https://github.com/talex5","followers_url":"https://api.github.com/users/talex5/followers","following_url":"https://api.github.com/users/talex5/following{/other_user}","gists_url":"https://api.github.com/users/talex5/gists{/gist_id}","starred_url":"https://api.github.com/users/talex5/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/talex5/subscriptions","organizations_url":"https://api.github.com/users/talex5/orgs","repos_url":"https://api.github.com/users/talex5/repos","events_url":"https://api.github.com/users/talex5/events{/privacy}","received_events_url":"https://api.github.com/users/talex5/received_events","type":"User","site_admin":false},"created_at":"2015-06-03T18:25:39Z","updated_at":"2015-06-03T18:25:39Z","body":"Here's a better trace, with the corresponding pcap:\r\n\r\n- http://test.roscidus.com/traces/ck-tcp2/\r\n- http://test.roscidus.com/traces/ck-tcp2/ck-from-laptop.pcap\r\n\r\nIt defaults to showing the region where the TCP thread for client port 40312 added some data to its `User_buffer.Tx`. The interesting thread is near the bottom; you'll need to drag upwards to see it (it's white, so easy to spot).\r\n\r\n1. It adds 1460 bytes to the buffer.\r\n2. It then adds a further 700 bytes.\r\n3. `clear_buffer` gets called to flush it, but `get_pkt_to_send` returns without doing anything because `tx_wnd` is zero.\r\n4. It seems that nothing ever flushes the buffer after that: the `User_buffer.Tx.bufbytes#40312` metric is still at its maximum at the end of the trace (I've hidden the other metrics; the HTML GUI doesn't let you toggle them yet).\r\n\r\nLooking at the pcap trace in wireshark with the filter `tcp.port eq 40312`, this connection was very simple:\r\n\r\n1. The TCP handshake completed.\r\n2. The client sent an SSL Client Hello.\r\n3. Shortly afterwards, it retransmitted it.\r\n4. It got an ack, then a duplicate ack.\r\n5. Later, there was a TCP Keep-Alice and ack.\r\n\r\nIs `tx_wnd` supposed to be zero here?"}}