Re: comments on RFC1323.bis

[Vern Paxson <[e-mail]>]

>   *> 	* The document doesn't specify the relationship between the
>   *> 	  options.  For example, if you use window scaling, then is
>   *> 	  it a MUST that you use timestamps too?  Or a SHOULD?  Or ... ?
>   *> 
> 
> Vern,
> 
> I don't think there is any relationship, except the obvious one that
> PAWS and RTTM both use timestamp options.  They are all recommended.

The relationship I was thinking of was that larger windows allow you to
transmit at higher speeds, and hence PAWS is of extra interest.

Even if there isn't a relationship between window scaling and timestamps,
it seems it would help if the document spells this out, as it's something
I found myself wondering as I read it.

I guess I'm also wondering whether "They are all recommended" means that
a TCP SHOULD implement these, or simply MAY implement them.  Since this is
standards-track, I think it's important to define what's expected of an
implementation.

> [changing the EWMA constants]
> 
> Yes!  This issue came up in the beginning but was never resolved.
> How much digital control (or filtering?) theory is required to
> answer this one?

Van & I discussed this a while ago, and his hit was that the whole RTO
algorithm should be rethought.  Since the goal is to form a good estimate
of an *upper bound* on RTT, then what's really of interest are maxima of
measured RTTs, and not some estimate of the mean RTT plus its variance
(which was just an attempt to estimate the maximum, given infrequent
sampling).  On our joint to-do list is to crunch some alternate algorithms
over the TCP traces I gathered for my thesis to see how well they do.

So, if you buy the above as a well-grounded statement, then I'd say that
this issue remains research, and for 1323.bis should be addressed simply by
noting that it is indeed such, and noting that the traditional constants
may lead to poor RTO estimates.

> How about if it says, "We believe that the increased performance resulting
> from the use of RTTM will more than pay for the extra header bandwidth".
> 
> If RTTM does not improve performance, why are we doing it???

Hmmmmm .... I can see a couple of ways in which it might pay off, neither
all that compelling.  The first is producing tighter estimates of RTO, so
that timeout retransmissions become less expensive.  That, though, requires
first addressing the above research item.  The second is that with RTTM you
can think about sender-side estimation of network path properties such as
bottleneck bandwidth (though you can do these without RTTM if you keep
track of each packet in flight anyway).

So I guess I'm not convinced we can say that RTTM itself buys anything.
I'd certainly be interested in hearing what I'm missing here.

>   *> +.\" "most recently received" conflicts with 3.4, which spells out
>   *> +.\" exactly which value is kept
> 
> My impression was that it did not really conflict, there is just some
> deliberate ambiguity at this point on what "most recently received"
> means.

(FWIW: as I read it I formed a mental model that it meant "by golly, the last
 one that arrived", and was confused because I knew it was more complicated
 than that.)

>   *> +RFC1122 requires TCP's to acknowledge every 2nd full-sized segment.
> 
> Nope.  It's only a SHOULD.

Well, not so clear.  4.2.3.2 says it SHOULD implement a delayed ack; the
context implies that this means as opposed to acking every packet.  The
following text states that acking every 2nd full-sized segment is a SHOULD;
but the table in 4.2.5 shows it as a MUST.

But I'd be happy with:

	RFC1122 states that TCP's SHOULD acknowledge every 2nd
	full-sized segment.

My main concern is that the text not imply that ack-every-K is just fine.

>   *> -timestamp from the most recent segment that advanced the window.
>   *> +timestamp from the most recent (in-order) segment that advanced the window.
> 
> ?? How can you advance the window without an in-order segment?  Adding
> the parenthetical phrase seems to me to be confusing without clarifying;
> am I missing something?

For me, from the earlier phrasing (regarding out-of-order) I had to pause
at this point to think "yes, it has to be in-order".  But if you find the
suggest phrase confusing rather than helpful, then go ahead and disregard it.

>   *>  [Braden89] Braden, R., editor,
>   *> +[Braden98] Braden, B., et al,
> 
> It is a little-known fact that these two characters are the same
> person... :-)

I suspected as much! :-)

(But I figured that this character likewise had control over their decisions
 regarding first initials, since they're lead author on both docs, and
 the above inconsistency is indeed how the docs read ...  but if you think
 you can somehow get their okay on rectifying the cites, then by all means
 go ahead!)

		Vern