Luca's profile - activity

Hello, @Packet_vlad. Thank you, that sounds very interesting.

@Christian_R, the issue did not reproduced with Jumbo Frames and reduced TCP window, so that was enough to close the cas

@Christian_R, issue did not reproduced with Jumbo Frames and reduced TCP window, so that was enough to close the case.

@Christian_R, will do that. I guess you actually meant tcp_sack = 1.

@ChristianR, will do that. I guess you actually meant tcp_sack = 1.

@Christian_R, will do that. I guess you actually meant tcp_sack = 1.

@Christian_R, will do that. I guess you actually meant tcp_sack = 1.

@Christian_R, we don't have direct access to the machine for netstat -s, but we will ask for it.

Can the TCP Window Scaling factor be directly configured? I see it is now 2048 in the second registration for the failin

Can the TCP Window Scaling factor be directly configured? I see it is now 2048 in the second registration for the failin

Hello, guys. So basically, the issue is systematically reproducible even with simulator applications, under the followi

Sender is a Windows desktop, while Receiver is on RedHat 6, June update, Kernel 2.6.32-754.2.1

Hello, guys. Thanks for you interest so far: this is getting pretty catchy. So I have another registration, washed with

Hello, guys. Thanks for you interest so far: this is getting pretty catchy. So I have another registration, washed with

Hello, guys. Thanks for you interest so far: this is getting pretty catchy. So I have another registration, washed with

Many thanks, @JimAragon. So we're basically stuck at the beginning: we have a recv box dropping 1460-byte packets, yet a

Many thanks, @JimAragon. So we're basically stuck to the beginning: we have a recv box dropping 1460-byte packets, yet a

Many thanks, @JimAragon. So we're basically stuck to the beginning: we have a recv box dropping 1460-byte packets, yet a

Many thanks, @Jim. So we're basically stuck to the beginning: we have a recv box dropping 1460-byte packets, yet acknowl

Yes, @Christian_R. It turned out jumbo frames were enabled everywhere, but on the sender box: so enabling it on the send

Yes, Christian_R. It turned out jumbo frames were enabled everywhere, but on the sender box: so enabling it on the sende

Not sure whether it could be pertinent or it just adds another variable into the picture, but... The issue seems to be e

Not sure whether it could be pertinent or it just adds another variable into the picture, but... The issue seems to be e

The receiver application is a Java application, using java.nio and non-blocking sockets. An incoming request could easil

The receiver application is a Java application, using java.nio and non-blocking sockets. An incoming request could easil

I understand the receiver application is temporarily busy and not consuming data from the receive window, while it is pe

Thanks guys. We will retry with the TCP scaling and window size changed, then. What remains unclear to me is why in such

Thanks, Cristian_R and Packet_vlad. I see all the points about reducing/slowing down the traffic by tuning the TCP windo

Thanks, Cristian_R and Packet_vlad. I see all the points about reducing/slowing down the traffic by tuning the TCP windo

Thanks, Maynard. This is a good hint - unfortunately, the original registrations are complete (possible that TraceWrangl

Yes, the conversation is across different networks, so as far as we know there is a Cisco device being traversed.

Yes, the conversation is across different networks, so as far as we know there is a Cisco switch being traversed.

Hi, I uploaded the peer registration: https://drive.google.com/open?id=1F57D6QiXyAdiG7UFId34C6LNgw69Qiwc Notes: 1) Trac

I can anticipate that the other peer registration is exactly dual: it contains the retransmissions for that packet, foll

I can anticipate that the other peer registration is exactly dual: it contains the retransmissions for that packet, foll

I can anticipate that the other peer registration is exactly dual: it contains the retransmissions for that packet, foll

Yes, cmaynard. Note the registrations were sanitized via TraceWrangler, so the IPs will appear randomized. I do have th

Yes, cmaynard. Note the registrations were sanitized via TraceWrangler, so the IPs will appear randomized. I do have th

Yes, cmaynard. Note the registrations were sanitized via TraceWrangler, so the IPs will appear randomized. I do have th

Hello, Christian. Thanks, I uploaded the receiver capture on Google Drive: https://drive.google.com/open?id=1V1mEuVV8T7O

Can you explain this Wireshark sequence Hello, Could anyone explain the behavior I observe below? I have the following

Can you explain this Wireshark TCP conversation? Hello, Could anyone explain the behavior I observe below? I have the f