0

I am searching for a method how I practically can determine the segments within a TCP window both when sending and receiving them?

I want to modify IP packets per TCP window.

I already looked into the IP and TCP header definition, took a look at TCP/IP packets using Wireshark and searched for python libraries, but did not find related work.

How to create a mapping between TCP segments or IP packets or fragments and TCP Windows?

I assume that knowledge on the start segment and end segment of a window might solve the problem.

I appreciate any answer, including theoretical approaches, that help determining what to do.

System is Linux using IPv6, though a generic answer is preferred.

7
  • 1
    Which window? The windows can and do change while packets are in flight. At which end are you getting the IP packets? – Ron Maupin Jun 7 at 16:18
  • I am in control of both ends. We are experimenting with an academic network layer protocol that works with TCP (but is not limited to). – kaiya Jun 7 at 18:07
  • 1
    So, the congestion window is only on the sending side, and it will grow until loss, then it will shrink. The receive window is maintained by the receiving side, and it gats sent to the sender in every ACK. Both windows will constantly change sizes, even while packets are in flight, and I really do not se how you will be able to say that ant packet X belongs to window Y. – Ron Maupin Jun 7 at 18:36
  • That's why I am asking if someone knows ;) (or can explain why this is not possible) – kaiya Jun 7 at 18:41
  • 1
    Which window? The receive window is open as long as there is receive buffer space, and it may never close, but there is no window number to relate to anything, just the current size is sent in every ACK. The congestion window is kept in the sender TCP, again no window numbers, and the TCP never sends out anything about the congestion window size. – Ron Maupin Jun 7 at 18:50
2

How to determine the distinct TCP segments or IP packets or fragments within a TCP Window?

Each segment is sent in a separate IP packet. Once reassembly of the original stream has started within the receive buffer (or window, if you like), you cannot make out which data went in which segment any more.

While the segments are still in transport, you can see the data stream alignment by the TCP header sequence number field.

4
  • Thanks so far. Yes, the SN gives me the alignment, so far I know, but what I additionally need is a mapping from window x to ip packet y r segment y. If possible at all, that is. – kaiya Jun 7 at 18:39
  • @kaiya, again, which window? Remember that the segments are independent of the windows. There are no window numbers. The receive window simply shrinks and grows as the receive buffer fills and empties, and its current size is sent in every AXK, but there really are not separate windows. The congestion window is not communicated, only maintained by the sending TCP, so you would need to have a hook into TCP on the sender to see the window size, which will grow until loss, then shrink and grow again. – Ron Maupin Jun 7 at 18:45
  • @kaiya There's no mapping from the (send?) window to any segment. The window is mapped to the data stream (like a virtually infinite buffer), as is each segment. That mapping is done by each sequence number. – Zac67 Jun 7 at 19:08
  • You are correct, I forgot that the windows are sliding. So, what I tried to ask for is not possible. – kaiya Jun 7 at 19:19
1

I am not really sure I understand what is the end goal here but technically there is a way to achieve what you're looking for. In order to do this you'd need to capture the beginning of the TCP conversation as this is the only place where during the three-way handshake parameters are agreed. Those parameters are quite important when it comes to TCP window (it's the only way to know what's the window size, if SACKs will be supported, scaling factor, etc). Using Wireshark and LUA you can script what you want, where basically you'd need to factor all the bytes sent by the sender for one window size and mark those accordingly (as rolling windows). Another optino using Wireshark is the "bytes in flight" which is in a way similar thing (it will give you the bytes that have been sent by the sender and have not yet been acknowledged). Again, I am not exactly sure what changes do you want to do to the IP packets, but maybe if you share more about your end goal - we could be able to give some additional guidance

2
  • 1
    "it's the only way to know what's the window size The congestion window is not communicated; it is only maintained by the sender. The receive window is communicated by the receiver in every ACK, and it shrinks and grows as the receive buffer is filled and emptied. – Ron Maupin Jun 7 at 18:38
  • 1
    Correct. I had in mind the receive window size which is communicated during the TCP handshake and it’s the only place where you can determine what is the window size if scaling factor is supported. The receive window size is communicated by the receiver in every ACK, but not the scaling factor (e.g. you won’t be able to tell the exact RWND size of the receiver that supports scaling factor if you don’t capture the first 3 packets of the session as you won’t know it). – Danail Petrov Jun 7 at 19:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.