2

RFC793 states that, at the receiver, the incoming segment is accepted upon the following check:

The first part of this test checks to see if the beginning of the segment 
falls in the window, the second part of the test checks to see if the end of
the segment falls in the window; if the segment passes either part of the 
test it contains data in the window. 

However, there may be a case that the the beginning of the segment falls in the window, but the end of the segment doesn't. This is he case when there still is room in the window, but the segment size is longer than the remaining space in the buffer. What if this is the case-- what happens?

Does TCP drop this segment? or Does it arrange the buffer based on Maximum Segment Size so that it can take these partial segments?

TIA.

1
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 12, 2017 at 19:06

3 Answers 3

4

The original question asked how a TCP handles a segment that partially overlaps the end of the receive window. RFC 793 answers this on page 82: "the local TCP considers that segments overlapping the range RCV.NXT to RCV.NXT + RCV.WND - 1 [meaning the receive window] carry acceptable data or control."

Therefore any segment that even partially overlaps the receive window, on either end, is kept. However, only the data inside the window is kept. The TCP can just discard the data outside the window and send an ACK for the highest sequence number kept.

(For a segment overlapping the end of the receive window, since the receiver can enlarge the window at any time, I believe it could also enlarge the window and keep the "extra" data that had been outside the old window. It would then send the appropriate ACK to show that that data had been accepted.)

The RFC also says that "Segments containing sequence numbers entirely outside of this range are considered duplicates and discarded", which again implies that segments not entirely outside the window are not discarded.

Also, a related case is mentioned on page 52: "When a segment overlaps other already received segments we reconstruct the segment to contain just the new data, and adjust the header fields to be consistent."

So, if the TCP had received two segments having a hole between them and then receives a segment that overlaps either or both, the TCP will create a new segment from the latest segment to fill the hole. For example:

S1 arrives:   [1000, 1800)
S3 arrives:   [1000, 1800)....hole....[1900, 2300)
S2 arrives:      [1700,                  2100)
Hole filled:  [1000, 1800)[1800, 1900)[1900, 2300)
2

A segment longer that the receiving window must be discarded, otherwise the receiver could get in a buffer overflow, and that could be exploited to hack the receiver's system.

The receiver is constantly letting know its receiving window value to the sender, so during normal operation the sender obeys that restriction.

Receiving a larger segment is a violation of the flow control rules and that's why it should be ignored.

0

Segment size(Size of a segment) is different from window size(Size of unacknowledged data)..

Segment size will be based on MSS(Maximum Segment Size of a sender/receiver) and path MTU where as window size might be larger than that and it don't have dependency on Segment size.. In that case if window size is larger, the data will be sent as multiple segments to accomplish the window..

Default Path MTU size is 1500 bytes if you take Ethernet (including all headers and payloads; MSS - 1460 bytes, Header and footer - 40bytes ) thus a packet size wont exceed this size..

RFC813 describes the stratagies of TCP windows

Let me explain with values. The numbers here are in bytes

MSS= 1460 bytes

Tcp Window = 56K = 56000

If the sender/reciever accepts the TCP negotiation session with these values and if there is a requirement for a large  data transfer, the sender will do like this

Each packet size will be 1500 bytes - Ethernet path MTU ( 1460 -MSS + 20 Byts IP header + 20 bytes TCP header)

At a time it will send 37 packets of 1500 bytes + 1 packet of 500bytes ( 1500bytes X 37 packets + 500bytes X 1packet = 56000) to complete the window of the size 56K.

Then it will wait for the acknowledment from receiver. Once it receives ACK, it can send again 56k Bytes as explained above

2
  • and how does this answer what i'm asking above. read the Q before answering.
    – ashley
    Oct 21, 2015 at 19:19
  • I am bit confused with your question. Can you clarify what are you referring as Segment in your question?? Are you referring transport layer segment?
    – G K
    Oct 24, 2015 at 19:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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