Folks-
I have several comments on the TCP over 2.5g/3g I-D -- some
small-ish, some more dignificant.
I am happy to clarify or iterate (via email or in Minneapolis) if
that is useful!
allman
-- Section 1:* "technology of both" --> "technology for both"
Section 2.1:
* "large enough window." --> "large enough window of outstanding data."
* I don't understand the sentence "For LFNs, it is necessary to utilize the available network bandwidth." Wouldn't the goal be to utilize the available bandwidth in *any* network?
* "worsening" --> "reduced"
Section 2.2:
* I don't understand the bit that says TCP can tolerate the asymmetry without need for congestion control. That seems busted to me.
Section 2.6:
* I do not understand the second paragraph at all. Why does it matter if the middle of the network changes to TCP? Specifically, why would it matter that window scaling is only negotiated at the beginning of a connection? I am sure I am missing something here, which likely means that you need to put a little more explanation in this paragraph.
Section 2.7:
* Lots of stuff about the RTO I don't like in this document. You say that the RTO is to closely follow the RTT. I am not sure I agree that this was a specific design goal. I think the RTO's job is to determine when a segment should be retransmitted (in the absence of an ACK). Sure, we use the RTT as the basis. But, we also figure in the jitter. And, in most networks the RTO is way conservative beyond this -- i.e., it does not try to track the RTT all that closely.
* "increasing frequency" --> "increasing the frequency"
* You note that the RFC 2988 based RTO estimator *reduces* spurious retransmits. What are you comparing it to? (I.e., there is not another standard RTO.)
* You note that increasing the RTT sampling can reduce spurious timeouts in BO systems. You should cite something here or remove the statement.
* You note that increasing cwnd is one way to avoid spurious RTOs. I don't understand this. When do we increas cwnd. This needs described better (and, a reference given, if possible).
Section 3:
* I chatted with Aaron about this today and he motivated this section for me as a bunch of information for those not terribly familiar with 2.5g and 3g technologies. So, this section seems fine as an educational tool to me. But, I think the intro should motivate that a little more.
Section 4:
* In the intro you note that all recommendations are in general purpose stacks and all are "safe". I'd go at it a little differently. I'd say that they are all IETF standards track mechanisms that the community has judged to be safe.
Section 4.1:
* "The traditional TCP" --> "The TCP"
Section 4.2:
* I'm sending a comment in a seperate email in hopes of catching Allison's attention.
Section 4.3:
* "4.2, TCP round trip" --> "4.2, TCP retransmission"
* I think the claim that LT is useful when sending small amounts of data might need hedged a little. If we run out of data to send we can send via LT (because LT calls for the sending of previously unsent data).
Section 4.6:
* "TCP may use" --> "TCP should use"
* "[39] semantics." --> "[39]."
Section 4.7:
* I'd note in the section title that you also need help from the routers in the network.
Section 4.8:
* First sentence needs a reference. * "one proposed in" --> "one specified in"
* I don't like the sentence about reference [44]. First, [44] is old. It may very well make that claim (which is likely from another source, actually). But, more recent expereince has suggested that this is not true. I suggest at least citing the work Vern and I did (SIGCOMM 99) that suggests that *in general networks* timing every RTT buys you little or nothing. It seems fine to me to recommend timing every segment in 2.5g/3g networks if you think that will help and you have references to back up that statement. However, I think your statements are too broad and should be tempered with some references to studies showing the flip side of the argument.
* I think [42] is being oversold. My reading of the I-D says that we should always get a bad RTO according to [42]. However, I would guess that is not the claim of [42] -- and if it is, it is wrong and I can find references that show it not to be the case all the time. I am guessing [42] does, indeed, show this behavior for *some* setup. So, the I-D should note that simple NS2 simulations of specific situations can show bad RTOs with no delay spike. And, I would also add the note that this is not general behavior when using an RFC 2988 compliant RTO. (Andrei- beat me up if I am way off here.)
This archive was generated by hypermail 2b29 : Sat Mar 16 2002 - 00:09:11 EST