Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt)

From: Mark Allman <[email-masked]>
Date: Mon, 02 Jun 2014 13:50:57 -0400

> Late negotiation has too many problems, as have been repeatedly
> raised on this list:
> 
> 	- prevents use of the timestamp to help address PAWS for
> 	the initial SYN

In the limit you're right that it is better to have a stronger
indication that the arriving SYN / SYN+ACK is not way old.  It is hard
to argue against such an ideal.  But, we run a whole bunch of
connections without timestamps today and it doesn't seem to have caused
us a whole bunch of problems.  So, while I can see your point I think it
is pretty esoteric.

Also, I'd like to know if OSes actually do consult the TS value in the
3WHS to try to hunt for old packets.  I have no idea.  Does anyone know?
(Either answer wouldn't surprise me, actually.)

> 	- a new connection that either avoids TS in SYN or
> 	uses just "use TS" (two-byte) flag can't know when
> 	to engage the timestamp and what initial value to use

This is just bogus.  On both counts.

(1) A TCP can in fact know when it should engage because it can in fact
    gauge its sending rate and relate that to the MSL.  And, if that is
    too complicated for a TCP to do---and it strikes me as such---then
    the TCP can turn it on when it approaches sequence wrap for the
    first time (i.e., sending 4GB of data).

(2) I don't see how the initial value we use here is different from the
    initial value we use at the beginning of a connection.  

Do we have to account for sending a TS mid-stream and it not being
supported by the other end?  Sure.  It seems the answer is to ensure the
sending rate is less than 4GB/MSL.  Is that extra work?  Sure.  Is it
worth it to save a wad of useless bytes in lots of packets on the
Internet?  That is a judgment call where reasonable people could
disagree, I guess.

allman

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 2 Jun 2014 18:08:54 +0000

> (Either answer wouldn't surprise me, actually.)

Well, I don't know.

But a related thought: In 1323bis we actually mention a random, per-connection offset. Such a logic in the 3WHS would have to take different offsets into account, right?

Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jun 2014 11:07:14 -0700

> (Either answer wouldn't surprise me, actually.)

The TWHS establishes the TS for the new connection, which means old 
packets will be seen as old and discarded by TS processing.

> This is just bogus.  On both counts.

FWIW, I'm saying that receiver has these problems. You're correct that 
the first TS value in an *acked* segment should be the one used and that 
the sender can know when to turn it on.

However, what if the receiver doesn't support TS at that point? How does 
it say so? At the least, TS-capable must be negotiated during the TWHS.

One question is - how many connections use TS that don't expect to use 
long connections or large numbers of connections where the sequence 
number wrap is an issue?

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jun 2014 11:11:56 -0700

On 6/2/2014 11:08 AM, Scharf, Michael (Michael) wrote:
> But a related thought: In 1323bis we actually mention a random,
> per-connection offset. Such a logic in the 3WHS would have to take
> different offsets into account, right?

Offsets should always move the clock forward; if they don't - if one 
offset is smaller than another for the same port pair - then 1323bis got 
it wrong.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 2 Jun 2014 18:25:52 +0000

> offset is smaller than another for the same port pair - then 1323bis

As far as I can see, draft-ietf-tcpm-1323bis-21 indeed mentions this requirement in Section 5.4, but it is not stated in the specific sentence that explains randomization.
 
Michael

---

From: Mark Allman <[email-masked]>
Date: Mon, 02 Jun 2014 15:49:06 -0400

> packets will be seen as old and discarded by TS processing.

OK, sure, fair enough.  But, again, we have plenty of non-timestamped
connections seemingly running perfectly fine today.  So, it is pretty
hard for me to get worked up about this "problem" the timestamp option
is "solving".

> FWIW, I'm saying that receiver has these problems. You're correct
> that the first TS value in an *acked* segment should be the one used
> and that the sender can know when to turn it on.

It doesn't matter if the receiver just follows the sender's lead.  The
sender can trigger things when they are needed and the receiver can
follow. 

> However, what if the receiver doesn't support TS at that point? 

If only I had said something about that in the note you are responding
to ... oh wait, I did! :-)

    Do we have to account for sending a TS mid-stream and it not being
    supported by the other end?  Sure.  It seems the answer is to ensure
    the sending rate is less than 4GB/MSL.  Is that extra work?  Sure.
    Is it worth it to save a wad of useless bytes in lots of packets on
    the Internet?  That is a judgment call where reasonable people could
    disagree, I guess.

This is pretty much a cwnd cap, so it isn't like it is rocket science
here. 

> One question is - how many connections use TS that don't expect to
> use long connections or large numbers of connections where the
> sequence number wrap is an issue?

I would say nearly all of them.

I'd bet a beer that you go look in your favorite pile of traces and
it'll be a Damn Long Time before you find even a potential problem that
timestamps will solve.

allman

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jun 2014 13:13:59 -0700

> to ... oh wait, I did! :-)

You talk about limiting the rate; that doesn't help a connection that 
cannot proceed because packets with the TS option are being dropped, 
e.g., by a midbox. That's why I don't like new stuff that starts out of 
the blue mid-connection - you need to negotiate the capability in the 
SYN at a minimum.

Further, what happens to the packets? When and how do you know when the 
TS isn't working? When do you give up?

Your rate limit suggestion answers just one dimension of the problem; 
there are a lot of others that need to be addressed.

> it'll be a Damn Long Time before you find even a potential problem that

1323bis talks about a list of mechanisms that rely on timestamps, more 
than just PAWS. What happens to those when TS is optional or started late?

Joe

---

From: Mark Allman <[email-masked]>
Date: Mon, 02 Jun 2014 16:35:40 -0400

> You talk about limiting the rate; that doesn't help a connection
> that cannot proceed because packets with the TS option are being
> dropped, e.g., by a midbox. 

Sure- in a spec you'd have to consider that.  But, I am not going to
pretend that it is difficult to detect and react to.

> Further, what happens to the packets? When and how do you know when
> the TS isn't working? When do you give up?

One RTT later.  Don't pretend this is difficult.  I didn't fully specify
it in an **email message**, but don't pretend this is some leap into
the Great Protocol Engineering Unknown, Joe.

> than just PAWS. What happens to those when TS is optional or started

If you want to use something and that something needs the TS option to
be on for the entire connection (e.g., Eifel) then you turn it on for
the entire connection.  Fine.  I have no problem with that.  But, then
you're not simply wasting 10 bytes in every packet, but you're getting
something for it.

However, on its own 1323(bis) wastes 10 bytes in every packet because
RTTM is not helpful and PAWS is nearly never needed.  So, it seems to me
that instead of dogmatically putting our foot down we could re-think
providing the information for PAWS when we actually need PAWS.  I guess
that is radical engineering or something, I dunno ...

allman

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 9 Jun 2014 11:48:08 -0700

> you're not simply wasting 10 bytes in every packet, but you're getting

Or we can just (dynamically) start tagging TS on retransmission to
support Eifel.

We have developed some nice features that use TS but 12 bytes is not trivial.
It could also cost a sack block. I would love to see proposals that
support these features w/o requiring always-on TS.

> RTTM is not helpful and PAWS is nearly never needed.  So, it seems to me

I second that TS RTTM is marginally helpful.

In non-retransmitted sequence it's useless b/c ACK/SACK take care of
it and they are less vulnerable to bad middleboxes. We've seen
middleboxes messing TS option values.
Even in retransmitted cases, TS can only be used if the ACK advances
SND_UNA. So if some retransmission are lost again then TS aren't
useful to get RTTM.
Therefore Linux has changed to use TS as the last resort in RTTM.
http://lxr.linux.no/linux+v3.15/net/ipv4/tcp_input.c#L2887

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Mark Allman <[email-masked]>
Date: Fri, 27 Jun 2014 08:41:26 -0400

[catching up after a long, pretty-much-offline vacation]

Just a quick note ..

> Or we can just (dynamically) start tagging TS on retransmission to

The pushback against this has always been that if you are retransmitting
a full packet and only add a TS on the retransmission, now you have to
retransmit two packets to convey all the lost data.

allman

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 27 Jun 2014 11:03:54 -0700

> retransmit two packets to convey all the lost data.

ah that's right. so this won't work (well) :_(