Sliding Window Question

ginkgo

is the sliding window mechanism responsible for a second transmission of a lost packet, or tcp itself ?

and another Question,
What problems does the sliding window mechanism have? i only read about the silly window syndrome, are there any others?

tmlerdal

the way I understood sliding window is that it just slows down the transmission by telling the sender to drop the window size.

But maybe I'm mistaken. I don't remember reading anything about it causing retransmissions.

tech-airman

ginkgo wrote:

is the sliding window mechanism responsible for a second transmission of a lost packet, or tcp itself ?

and another Question,
What problems does the sliding window mechanism have? i only read about the silly window syndrome, are there any others?

ginkgo,

Remember from your CCNA studies about the overall encapsulation and decapsulation process.

Remember that initially, host1 needs to SYNchronize with host2. After they are synhronized, then host2 sends an ACK back to host1 with the value of the sequence number which is a field in the TCP header of the segment sent from host2 to host1. Let's say for simplicity, the first sequence number is 1. Then when host1 receives the ACK segment, host 1 assumes a TCP window size of 4, host1 sends segment 1, 2, 3, then 4 to host2. However, host2 may be busy so it was only able to receive segments 1, 2, and 3 but not segment 4. So this is when sliding windows starts. Host2 sends an ACK back to host1 with sequence number 4 because it didn't receive segment 4. So when host1 receives that ACK of 4, first it adjusts it's assumption of TCP window from 4 to 3. Then host1 sends segments 4, 5, and 6 because now the TCP window size is 3 instead of the previous 4. So in conclusion, sliding windows mechanism is a subcomponent of TCP.

I hope this helps.

EdTheLad

ginkgo wrote:

is the sliding window mechanism responsible for a second transmission of a lost packet, or tcp itself ?

and another Question,
What problems does the sliding window mechanism have? i only read about the silly window syndrome, are there any others?

Tcp is responsible for the retransmission of a lost packet and it can do it in two ways.Everytime a
segment is transmissed a duplicate copy is placed in a retransmit buffer.If an Ack is not received within the retransmit timeout interval TCP will retransmit the segment, also if three of more Ack's are received indicating the same seq number it indicates a segment loss and a retransmit occurs.

As far as i'm aware the only issue with the sliding window is the silly window syndrome, since the maximum segment size is negotiated during synchronization the only issue can be the window size decreasing to a small size. This syndrone isn't an issue anymore as tcp fixes this on both sender and receiver by introducing delay timers and minimum window sizes in Ack, if the receiving buffer falls below the minimum window size the Window size will be set to zero in the Ack.

tech-airman wrote:

ginkgo,

Remember from your CCNA studies about the overall encapsulation and decapsulation process.

Remember that initially, host1 needs to SYNchronize with host2. After they are synhronized, then host2 sends an ACK back to host1 with the value of the sequence number which is a field in the TCP header of the segment sent from host2 to host1. Let's say for simplicity, the first sequence number is 1. Then when host1 receives the ACK segment, host 1 assumes a TCP window size of 4, host1 sends segment 1, 2, 3, then 4 to host2. However, host2 may be busy so it was only able to receive segments 1, 2, and 3 but not segment 4. So this is when sliding windows starts. Host2 sends an ACK back to host1 with sequence number 4 because it didn't receive segment 4. So when host1 receives that ACK of 4, first it adjusts it's assumption of TCP window from 4 to 3. Then host1 sends segments 4, 5, and 6 because now the TCP window size is 3 instead of the previous 4. So in conclusion, sliding windows mechanism is a subcomponent of TCP.

I hope this helps.

Just thought i'd comment on your answer to make it a little clearer, during the synch process each devices exchanges sequence numbers and other connection parameters like MSS max segment size.Each device has a receive buffer which ultimately controls the maximum window size possible.When a connection initializes it starts with a window size of one or two times the MSS, so the receiver doesn't assume a random value.The MSS is dependent on layer 3 as TCP tries to fit its segments into a single IP datagram to avoid IP fragmentation.
After every Ack received the window size is increased by one MSS, this window size will increase to a maximum of the receivers buffer, if a segment is lost the window size will reduce back to the original MSS size.
The window size indicates the number of bytes that can be transmitted and not the number of segments, the segment size can vary depending on the space available in the receivers buffer.So in the example above segments 1,2,3 and 4 will be received into the receivers buffer but only segments 1,2 and 3 are transmitted to the higher layers as the TCP layer is being overrun.Since
segment 4 has been received an ACK will be sent with 5 and the window size is decreased by the number of byte in segment 4, basically telling the sender the amount of bytes that the receivers buffer can handle.
If the receivers buffer could only hold segments 1,2 and 3 with 4 being discarded, the senders would become aware segment 4 is missing due to the retransmit timer expiring i.e. no Ack is received indicating 5 or on receipt of multiple Ack indicating segment 4.As a result segment 4 would be retransmitted and the window size decreased to MSS as part of the congestion avoidance mechanism.