It's difficult to understand the TCP RFC...

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

It's difficult to understand the TCP RFC...

Natale Patriciello
... after hours of readings. Yes, I can say that from personal
experience. My question is how you interpret the following paragraph,
taken from RFC 5681:

That is, when the first loss in a window of data is detected, ssthresh
MUST be set to no more than the value given by equation (4). Second,
until all lost segments in the window of data in question are repaired,
the number of segments transmitted in each RTT MUST be no more than half
the number of outstanding segments when the loss was detected.

(At the end of page 11). I would like to be a bit more precise: do you
think that the following image (taken from
http://cnp3book.info.ucl.ac.be/2nd/html/_images/transport-fig-094-c.png)
does represent the words quoted from the RFC? (I added, for your
convenience, an interesting point in red)

http://imgur.com/a/f66sA

I added the exact moment in which the sender receives the full
acknowledgment, i.e., when it receives the ACK that covers all the
sequences transmitted before it got the triple DupACK that triggered the
Fast Retransmit. Please note that the original image is just what we had
on the books for years for Reno/NewReno.

Thank you
Nat
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: It's difficult to understand the TCP RFC...

Tom Henderson-2
On 02/19/2017 02:13 PM, Natale Patriciello wrote:
> ... after hours of readings. Yes, I can say that from personal
> experience. My question is how you interpret the following paragraph,
> taken from RFC 5681:
>
> That is, when the first loss in a window of data is detected, ssthresh
> MUST be set to no more than the value given by equation (4). Second,
> until all lost segments in the window of data in question are repaired,
> the number of segments transmitted in each RTT MUST be no more than half
> the number of outstanding segments when the loss was detected.

I think that it is saying that the window inflation might result in the
ability to send more than FlightSize/2 so it is capping it as
FlightSize/2.  For instance, SACK may report on the loss of many
segments in that window.

>
> (At the end of page 11). I would like to be a bit more precise: do you
> think that the following image (taken from
> http://cnp3book.info.ucl.ac.be/2nd/html/_images/transport-fig-094-c.png)
> does represent the words quoted from the RFC? (I added, for your
> convenience, an interesting point in red)
>
> http://imgur.com/a/f66sA

The drawing does not depict the number of segments sent, but the
(idealized) evolution of cwnd.

- Tom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: It's difficult to understand the TCP RFC...

Natale Patriciello
On 20/02/17 at 06:43, Tom Henderson wrote:

> >
> > (At the end of page 11). I would like to be a bit more precise: do you
> > think that the following image (taken from
> > http://cnp3book.info.ucl.ac.be/2nd/html/_images/transport-fig-094-c.png)
> > does represent the words quoted from the RFC? (I added, for your
> > convenience, an interesting point in red)
> >
> > http://imgur.com/a/f66sA
>
> The drawing does not depict the number of segments sent, but the (idealized)
> evolution of cwnd.
>

Thanks Tom for the reply.
But, if we receive the full ACK where there is the red pointer, then the
reported evolution is incorrect, because it should have been kept fixed at the
threshold value. What I would like to say is that by strictly
following the RFCs, the congestion window is fixed at the threshold
value from the instant we get the 3rd duplicated ACK, until we get a
full ack. Is that correct ?

Nat
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: It's difficult to understand the TCP RFC...

Tom Henderson-2
On 02/20/2017 07:59 AM, Natale Patriciello wrote:

> On 20/02/17 at 06:43, Tom Henderson wrote:
>>>
>>> (At the end of page 11). I would like to be a bit more precise: do you
>>> think that the following image (taken from
>>> http://cnp3book.info.ucl.ac.be/2nd/html/_images/transport-fig-094-c.png)
>>> does represent the words quoted from the RFC? (I added, for your
>>> convenience, an interesting point in red)
>>>
>>> http://imgur.com/a/f66sA
>>
>> The drawing does not depict the number of segments sent, but the (idealized)
>> evolution of cwnd.
>>
>
> Thanks Tom for the reply.
> But, if we receive the full ACK where there is the red pointer, then the
> reported evolution is incorrect, because it should have been kept fixed at the
> threshold value. What I would like to say is that by strictly
> following the RFCs, the congestion window is fixed at the threshold
> value from the instant we get the 3rd duplicated ACK, until we get a
> full ack. Is that correct ?

I think the diagram is not really depicting the dynamics of what happens
during fast recovery; I think your red arrow is pointing to a region
that is post-recovery.

During the recovery (whose timescale might be small in relation to that
figure), cwnd is not held fixed but is incremented by one segment for
each subsequent dupack and it might look more jagged like this figure:
http://images.slideplayer.com/11/3391253/slides/slide_19.jpg

- Tom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: It's difficult to understand the TCP RFC...

Natale Patriciello
On 20/02/17 at 08:17, Tom Henderson wrote:
> I think the diagram is not really depicting the dynamics of what happens
> during fast recovery; I think your red arrow is pointing to a region that is
> post-recovery.
>
> During the recovery (whose timescale might be small in relation to that
> figure), cwnd is not held fixed but is incremented by one segment for each
> subsequent dupack and it might look more jagged like this figure:
> http://images.slideplayer.com/11/3391253/slides/slide_19.jpg
>

Good !

Ns-3 right now is following the black continuos line in that figure, which I think
represents the number of in-flight bytes, avoiding the inflation and the
deflation mechanism. Probably this would deserve a paragraph in the
ns-3 documentation.

But, going forward: we all know the shape of Bic and Cubic congestion
control algorithms, we never see these steady points after the fast
retransmit. Does that mean that Bic and Cubic does not follow what is
stated in the RFC, and that the number of in-flight bytes is not
constant during the fast recovery? I think the answer is yes.

Nat
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: It's difficult to understand the TCP RFC...

Tom Henderson-2
On 02/20/2017 08:25 AM, Natale Patriciello wrote:

> On 20/02/17 at 08:17, Tom Henderson wrote:
>> I think the diagram is not really depicting the dynamics of what happens
>> during fast recovery; I think your red arrow is pointing to a region that is
>> post-recovery.
>>
>> During the recovery (whose timescale might be small in relation to that
>> figure), cwnd is not held fixed but is incremented by one segment for each
>> subsequent dupack and it might look more jagged like this figure:
>> http://images.slideplayer.com/11/3391253/slides/slide_19.jpg
>>
>
> Good !
>
> Ns-3 right now is following the black continuos line in that figure, which I think
> represents the number of in-flight bytes, avoiding the inflation and the
> deflation mechanism. Probably this would deserve a paragraph in the
> ns-3 documentation.
>
> But, going forward: we all know the shape of Bic and Cubic congestion
> control algorithms, we never see these steady points after the fast
> retransmit. Does that mean that Bic and Cubic does not follow what is
> stated in the RFC, and that the number of in-flight bytes is not
> constant during the fast recovery? I think the answer is yes.

According to the I-D, CUBIC changes the behavior after the fast
recovery, but not during:
https://tools.ietf.org/html/draft-ietf-tcpm-cubic-04#section-4.1

- Tom
Loading...