Subject: [tcpm] TS & SACK

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 5 Nov 2010 00:29:45 -0000

Hi group,

I would like to learn your thoughts revolving around the following
though - and I admit, that most likely, there are some angels that I
haven't looked at yet:

According to RFC1323:

Sender:
TSecr is to be ignored for RTTM purposes, if the ACK carrying it
cumulatively acks some new data.
Receiver:

Section 3.4 defines, which TS the receiver should echo. Especially case
B is very important, if no further information is available. Overall,
this section 3.4 seems to again specify, that the receiver should only
echo the TS of the data segment, that lead to an cumulative ack of new
data (except for delayed ACKs, where the TS of the first new data
segment is to be used).

It appears to me, that with the exception of rule 3.4 / A, talking about
the delayed ack case, the cases B and C are redundant with what a sender
can use for RTTM (PAWS) anyway.

Now, since 3.3 (sender RTTM calculation) and 3.4/B | 3.4/C seem to be
redundant, having a SACK-enabled TCP receiver to continue to reflect
back the TS of the last received (and newly SACKed) data segment should
not have a detrimential effect (proper implementations assumed). 

The upside of having the TS is to gain more insight into the state of
the network, as the combination of SACK + TS information can reveal
exactly, if reordering or loss exists in the network, allowing a TCP
sender a more targeted response during SACK loss recovery. (Some of this
is also possible by using DSACK, of course).

The basic idea (brought up by D. Damjanovic in a discussion) is to know
more which segment is newly SACKed - with TS delivering the necessary
tag - so that spurious retransmissions can be avoided, while lost
retransmissions can be detected at the earliest possibility.

If a TCP receiver doesn't reflect the TS option on ACK+SACKs, a TCP
sender making use of this scheme would revert to the current scheme used
by Linux to recover lost retransmissions (which requires a cumulative
ACK beyond RP, and incidentially carries a new TSecr).

Is the above assesment, that the two sections 3.3 and 3.4 are largely
redundant in RFC1323, correct? Or did I skip some important line, that
explains why it's defined that way (w/ redundancy).

Thanks a lot,

Richard Scheffenegger

---

From: Alexander Zimmermann <[email-masked]>
Date: Fri, 05 Nov 2010 09:37:55 +0100

Hi Richard,

just my 2cents...

Am 05.11.2010 um 01:29 schrieb Scheffenegger, Richard:

>  Hi group,
> 
> 
> I would like to learn your thoughts revolving around the following though - and I admit, that most likely, there are some angels that I haven't looked at yet:
> 
> According to RFC1323:
> 

You know that Section 3.4 of RFC1323 is wrong and that an update exists:
http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-1323bis/
> Sender: 
> TSecr is to be ignored for RTTM purposes, if the ACK carrying it cumulatively acks some new data. 
> Receiver:
> 
I'm sure you mean the opposite...

Copied from Section 3.3

A TSecr value received in a segment is used to update the averaged RTT measurement
only if the segment acknowledges some new data, i.e., only if it advances the left edge of
the send window.
> Section 3.4 defines, which TS the receiver should echo. Especially case B is very important, if no further information is available. Overall, this section 3.4 seems to again specify, that the receiver should only echo the TS of the data segment, that lead to an cumulative ack of new data (except for delayed ACKs, where the TS of the first new data segment is to be used).
> 
> It appears to me, that with the exception of rule 3.4 / A, talking about the delayed ack case, the cases B and C are redundant with what a sender can use for RTTM (PAWS) anyway.
> 
I don't think that cases b and c are redundant. In my point of view case b explains why we should
"artificially inflate" the RTT, while case c explains why we can stop with this and can each back
the "real" value. Moreover, all 3 cases are only explanations, the real algorithm comes later
(steps 1, 2, 3)

> 
> Now, since 3.3 (sender RTTM calculation) and 3.4/B | 3.4/C seem to be redundant, having a SACK-enabled TCP receiver to continue to reflect back the TS of the last received (and newly SACKed) data segment should not have a detrimential effect (proper implementations assumed).
> 
> The upside of having the TS is to gain more insight into the state of the network, as the combination of SACK + TS information can reveal exactly, if reordering or loss exists in the network, allowing a TCP sender a more targeted response during SACK loss recovery. (Some of this is also possible by using DSACK, of course).
> 
> The basic idea (brought up by D. Damjanovic in a discussion) is to know more which segment is newly SACKed - with TS delivering the necessary tag - so that spurious retransmissions can be avoided, while lost retransmissions can be detected at the earliest possibility.
> 
> If a TCP receiver doesn't reflect the TS option on ACK+SACKs, a TCP sender making use of this scheme would revert to the current scheme used by Linux to recover lost retransmissions (which requires a cumulative ACK beyond RP, and incidentially carries a new TSecr).
> 
> 
> 
> Is the above assesment, that the two sections 3.3 and 3.4 are largely redundant in RFC1323, correct? Or did I skip some important line, that explains why it's defined that way (w/ redundancy).
> 
> Thanks a lot, 
>  
> 
> Richard Scheffenegger
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 5 Nov 2010 21:16:08 -0000

Hi Alexander,

________________________________

	From: Alexander Zimmermann
[mailto:[email-masked]] 
	Sent: Freitag, 05. November 2010 09:38
	To: Scheffenegger, Richard
	Cc: [email-masked]
	Subject: Re: [tcpm] TS & SACK

	Hi Richard, 

	just my 2cents...

		 Hi group, 

		I would like to learn your thoughts revolving around the
following though - and I admit, that most likely, there are some angels
that I haven't looked at yet:

		According to RFC1323: 

	You know that Section 3.4 of RFC1323 is wrong and that an update
exists:
	http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-1323bis/ 

Thanks for the hint with the revised version! 

		Sender: 
		TSecr is to be ignored for RTTM purposes, if the ACK
carrying it cumulatively acks some new data. 
		Receiver:

	Copied from Section 3.3

	A TSecr value received in a segment is used to update the
averaged RTT measurement
	only if the segment acknowledges some new data, i.e., only if it
advances the left edge of
	the send window. 

certainly, i did some editing and forgot to proof-read before i hit
send.

		Section 3.4 defines, which TS the receiver should echo.
Especially case B is very important, if no further information is
available. Overall, this section 3.4 seems to again specify, that the
receiver should only echo the TS of the data segment, that lead to an
cumulative ack of new data (except for delayed ACKs, where the TS of the
first new data segment is to be used).

		It appears to me, that with the exception of rule 3.4 /
A, talking about the delayed ack case, the cases B and C are redundant
with what a sender can use for RTTM (PAWS) anyway.

	I don't think that cases b and c are redundant. In my point of
view case b explains why we should
	"artificially inflate" the RTT, while case c explains why we can
stop with this and can each back
	the "real" value. Moreover, all 3 cases are only explanations,
the real algorithm comes later
	(steps 1, 2, 3) 

Well, redundant in the sense, that the sender will ignore any timestamp
as per section 3.3 rule, as long as no new data is cumulatively acked. 
 
For point B, if the sender ignores the TS anyway (section 3.3), there is
no point in reporting an inflated RTT. (The TS of the ACK for an
out-of-order segment is to be ignored - for RTTM -, as it doesn't
advance the left edge of the window, correct?). For all a RFC1323(bis)
sender cares, the timestamp could be any number, which only fullfils the
PAWS requirements, but has no further RTTM function.
 
For point C, the ACK advances, and the RTTM should be updated with a
reasonable RTTM estimate, that is not artifically inflated, thus the TS
of the data segment which filled the (leftmost?) hole. Or does point C
also apply when a hole further right (thus not advancing cumulative ACK)
is filled? (Per 3.3, that TS should be ignored again; but point C is
IMHO ambigious here).

So, my question is this: As a sender should ignore a TS for RTTM
purposes if the cumulative ACK is not advanced, why go though the hassle
of defining point B in section 3.4 to that length?; and how is point C
to be interpreted - any hole being filled, only the leftmost hole? (The
pseudo-code (2) implicitly only allows for the leftmost hole :) ).

Thanks for bearing with me!
 
Best regards,
   Richard 

		

		Now, since 3.3 (sender RTTM calculation) and 3.4/B |
3.4/C seem to be redundant, having a SACK-enabled TCP receiver to
continue to reflect back the TS of the last received (and newly SACKed)
data segment should not have a detrimential effect (proper
implementations assumed). 

		The upside of having the TS is to gain more insight into
the state of the network, as the combination of SACK + TS information
can reveal exactly, if reordering or loss exists in the network,
allowing a TCP sender a more targeted response during SACK loss
recovery. (Some of this is also possible by using DSACK, of course).

		The basic idea (brought up by D. Damjanovic in a
discussion) is to know more which segment is newly SACKed - with TS
delivering the necessary tag - so that spurious retransmissions can be
avoided, while lost retransmissions can be detected at the earliest
possibility.

		If a TCP receiver doesn't reflect the TS option on
ACK+SACKs, a TCP sender making use of this scheme would revert to the
current scheme used by Linux to recover lost retransmissions (which
requires a cumulative ACK beyond RP, and incidentially carries a new
TSecr).

		Is the above assesment, that the two sections 3.3 and
3.4 are largely redundant in RFC1323, correct? Or did I skip some
important line, that explains why it's defined that way (w/ redundancy).

		Thanks a lot, 

		Richard Scheffenegger

	

	//

---

From: Alexander Zimmermann <[email-masked]>
Date: Mon, 08 Nov 2010 19:56:45 +0100

Am 05.11.2010 um 22:16 schrieb Scheffenegger, Richard:

> Well, redundant in the sense, that the sender will ignore any timestamp as per section 3.3 rule, as long as no new data is cumulatively acked.
>  
> For point B, if the sender ignores the TS anyway (section 3.3), there is no point in reporting an inflated RTT. (The TS of the ACK for an out-of-order segment is to be ignored - for RTTM -, as it doesn't advance the left edge of the window, correct?). For all a RFC1323(bis) sender cares, the timestamp could be any number, which only fullfils the PAWS requirements, but has no further RTTM function.
>  
> For point C, the ACK advances, and the RTTM should be updated with a reasonable RTTM estimate, that is not artifically inflated, thus the TS of the data segment which filled the (leftmost?) hole.

IMO leftmost.

> Or does point C also apply when a hole further right (thus not advancing cumulative ACK) is filled?

IMO no.

> (Per 3.3, that TS should be ignored again; but point C is IMHO ambigious here).

Yes, (maybe) it is ambiguous. RFC5681, Section 4.2. Generating Acknowledgments, next-to-last paragraph has
the same "hole-ambiguous-problem".

But on the other hand, the problem is maybe that we have the "SACK-Glass" on. Without SACK in mind, the wording
is OK. (But can improved in 1323bis)

>  
>  
> So, my question is this: As a sender should ignore a TS for RTTM purposes if the cumulative ACK is not advanced, why go though the hassle of defining point B in section 3.4 to that length?;

Hmm, good question. I have to think about it. At first glance, your reasoning sounds good and I cannot
see a mistake. However, I have also the feeling that V. Jacobson is cleverer that I...

Did you take a look into the bible? (Stevens TCP/IP Illustrated)

> and how is point C to be interpreted - any hole being filled, only the leftmost hole? (The pseudo-code (2) implicitly only allows for the leftmost hole :) ).
>  
>  

//

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 9 Nov 2010 01:13:55 -0000

HI Alexander,

		

				Section 3.4 defines, which TS the
receiver should echo. Especially case B is very important, if no further
information is available. Overall, this section 3.4 seems to again
specify, that the receiver should only echo the TS of the data segment,
that lead to an cumulative ack of new data (except for delayed ACKs,
where the TS of the first new data segment is to be used).

				It appears to me, that with the
exception of rule 3.4 / A, talking about the delayed ack case, the cases
B and C are redundant with what a sender can use for RTTM (PAWS) anyway.

			I don't think that cases b and c are redundant.
In my point of view case b explains why we should
			"artificially inflate" the RTT, while case c
explains why we can stop with this and can each back
			the "real" value. Moreover, all 3 cases are only
explanations, the real algorithm comes later
			(steps 1, 2, 3) 

		Well, redundant in the sense, that the sender will
ignore any timestamp as per section 3.3 rule, as long as no new data is
cumulatively acked. 
		 
		For point B, if the sender ignores the TS anyway
(section 3.3), there is no point in reporting an inflated RTT. (The TS
of the ACK for an out-of-order segment is to be ignored - for RTTM -, as
it doesn't advance the left edge of the window, correct?). For all a
RFC1323(bis) sender cares, the timestamp could be any number, which only
fullfils the PAWS requirements, but has no further RTTM function.
		 
		For point C, the ACK advances, and the RTTM should be
updated with a reasonable RTTM estimate, that is not artifically
inflated, thus the TS of the data segment which filled the (leftmost?)
hole.

	IMO leftmost.

		Or does point C also apply when a hole further right
(thus not advancing cumulative ACK) is filled?

	IMO no.

		(Per 3.3, that TS should be ignored again; but point C
is IMHO ambigious here).

	Yes, (maybe) it is ambiguous. RFC5681, Section 4.2. Generating
Acknowledgments, next-to-last paragraph has
	the same "hole-ambiguous-problem".

	But on the other hand, the problem is maybe that we have the
"SACK-Glass" on. Without SACK in mind, the wording
	is OK. (But can improved in 1323bis) 

Let's keep that aspect aside; it's pretty clear that the leftmost hole
(which will result in a changed cumulative ACK) is meant.

		So, my question is this: As a sender should ignore a TS
for RTTM purposes if the cumulative ACK is not advanced, why go though
the hassle of defining point B in section 3.4 to that length?;

	Hmm, good question. I have to think about it. At first glance,
your reasoning sounds good and I cannot
	see a mistake. However, I have also the feeling that V. Jacobson
is cleverer that I...

Just did. However, RFC1323 is not discussed there in that detail to
yield the insight I'm looking for. Perhaps V. Jacobson could provide the
background - it might be as simple as a belt-and-suspenders additional
safety net, if either receiver or sender have implementation bugs...   
 
Best regards,
   Richard