Re: comments on RFC1323.bis

[[e-mail]]

  *> Some other issues:
  *> 
  *> 	* 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.

   *> 
  *> 	* A significant technical issue: the current RTTM discussion
  *> 	  does not mention anything about altering the constants used
  *> 	  for the exponentially-weighted moving average when updating
  *> 	  the estimate of RTT.  Sally Floyd has pointed out that using
  *> 	  the usual constants is incorrect when the RTT is updated more
  *> 	  than once per window; their use will result in an RTT estimate
  *> 	  that is much more sensitive to transient changes in RTT.
  *> 
  *> 	  I think at a minimum the document needs to point out that
  *> 	  there is an open issue here.
  *> 

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?


...

  *> @@ -333,6 +338,12 @@
  *>  segment, adding 12 bytes to the 20-byte TCP header.  We
  *>  believe that the bandwidth saved by reducing unnecessary
  *>  retransmissions will more than pay for the extra header bandwidth.
  *> +.\" How does the Timestamps option help with reducing unnecessary
  *> +.\" retransmissions?  It only will if currently the RTO estimates
  *> +.\" are too low.  While some TCP implementations suffer from this
  *> +.\" problem, most do not.  In particular, using the coarse-grained
  *> +.\" BSD RTO algorithm works quite conservatively.  So this argument
  *> +.\" is not right.

Hum.  As I recall, this was taken directly from a comment by Van.
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???


  *> @@ -608,6 +619,8 @@
  *>  represent the corresponding cumulative acknowledgments.  The two
  *>  timestamp fields of the Timestamps option are shown symbolically as
  *>  <TSval= x,TSecr=y>.  Each TSecr field contains the value most recently
  *> +.\" "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.

  *>  .nf
  *> @@ -625,7 +638,11 @@
  *>  4.  (130)  <--- <ACK(B),TSval=130,TSecr=6>             (6)
  *>                  
  *>         . . . ( Pause for 60 timestamp clock ticks ) . . . . 
  *> -                  
  *> +
  *> +.\" This formatting is messed up.  Epochs 4 and 5 appear
  *> +.\" twice.  In the first 4, TS.Recent is 130, but in the
  *> +.\" subsequent 5, we have TSecr=120.  Also, why in 5 is
  *> +.\" TSval=1??
  *>        
  *>  5.  (130)             <C,TSval=1,TSecr=120> --->       (1)
  *>           
  *> @@ -636,6 +653,8 @@
  *>  5.            ... <--- <y,ACK(A),TSval=191,TSecr=5>    (5)
  *>  
  *>  
  *> +.\" What is the point of this second, less precisely specified
  *> +.\" example??
  *>  

I will have to review all this; I thought we had it right in
the original document.

  *>     TCP  A                                          TCP B
  *>        
  *> @@ -685,8 +704,8 @@
  *>  .LT (A) 0.5i
  *>  Delayed ACKs.
  *>  .sp
  *> -Many TCP's acknowledge only every Kth segment out of a group of
  *> -segments arriving within a short time interval; this policy is known
  *> +RFC1122 requires TCP's to acknowledge every 2nd full-sized segment.

Nope.  It's only a SHOULD.

  *> +The policy of acknowledging only every 2nd segment is known
  *>  generally as "delayed ACKs".  The data-sender TCP must measure the
  *>  effective RTT, including the additional time due to delayed ACKs, or
  *>  else it will retransmit unnecessarily.  Thus, when delayed ACKs are in
  *> @@ -704,7 +723,7 @@
  *>  situation the sender should be conservative about retransmission.
  *>  Furthermore, it is better to overestimate than underestimate the RTT.
  *>  An ACK for an out-of-order segment should therefore contain the
  *> -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?


  *> @@ -939,12 +962,15 @@
  *>  If B's retransmission was triggered by the "fast retransmit" algorithm,
  *>  i.e., by duplicate ACKs, then the queued segments that caused these
  *>  ACKs must have been received already.
  *> +.\" .sp
  *> +.\" Even if a segment were delayed past the RTO, the Fast Retransmit
  *> +.\" mechanism [Jacobson90c] will cause the delayed
  *> +.\" packets to be retransmitted at the same time as B.2, avoiding an extra
  *> +.\" RTT and therefore causing a very small performance penalty.
  *> +.\"
  *> +.\" ^^^^ This isn't right: fast retransmission will only retransmit
  *> +.\" one packet, not all of the delayed packets.

(Will have to review this)


  *> @@ -1179,8 +1205,19 @@
  *>  .ne 2
  *>  [Braden89] Braden, R., editor,
  *> +[Braden98] Braden, B., et al,

It is a little-known fact that these two characters are the same
person... :-)

  *> @@ -1972,7 +2019,15 @@
  *>  .ne 3
  *>  .LT "Security Considerations" 0.3i
  *>  .sp
  *> -Security issues are not discussed in this memo.
  *> +"Security issues are not discussed in this memo" is no longer
  *> +acceptable.  A few considerations that come to mind: window scaling
  *> +makes denial-of-service easier if one can find an endless TCP data source
  *> +(such as chargen) since it can be made to send data at a higher rate
  *> +than it otherwise could; if mandatory, timestamps could making TCP
  *> +spoofing more difficult, because the spoofer has a harder time crafting
  *> +the timestamp echoes for the spoofed side of the connection; accepting
  *> +RSTs regardless of their timestamps doesn't make it any harder or
  *> +easier to spoof RST packets.
  *>  .sp

Gack.  This needs discussion...

Bob Braden