Re: comments on RFC1323.bis

[[e-mail]]

   *> 
  *> 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.
  *> 

Vern,

I didn't think that 'standards track' necessarily implies that the RFC
must combine technical definition and Applicability Statement, but
it seems like a good idea in this case, at least.

It was certainly the intent of the original authors that it ought to be
a (strong) SHOULD.  However, your comments on RTTM call this into
question.


  *> > [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.
  *> 
Eeeergggg.  No, that cannot the right answer.  The message you are sending
is "You should implement this to improve RTO estimates and get better
performance, but if you use the current constants you may get worse RTO
estimates and we can't tell you what constants to use".  We might as
well go home now and forget it.

Did you notice that Van did not answer your question?  Does that mean
there is some terrible flaw in the current scheme, so that NO values of
the constants will actually improve the RTO?  If the answer is "yes",
we should abandon RTTM now; otherwise, we should be able to specify
recommended constants in the document, even if they may be improved
with subsequent research.

  *> 
  *> >   *> +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.
  *> 

Ooo, ooo, ooo!  You've found a bug in RFC1122!!

Bob