Subject: Re: Comments on draft-ietf-pilc-2.5g3g-01.txt

From: "Hiroshi INAMURA" <[email-masked]>
Date: Wed, 6 Jun 2001 16:45:27 +0900

Mark,

Thanks for your comments. I've incorporated much of your comments. The full
　text of the draft will be sent in a separate message. The following is my
　responses.

Hiroshi Inamura
NTT DoCoMo

> Section 3.1.1:
>
>   * You use "64 KB" as the capacity of a link.  This is not
>     correct.  (And, more generally the BDP that matters is based on
>     the bandwidth and delay of a network path, not a link.  I think
>     the draft generally needs cleaned up on this point).

I've reworked on the use of words 'link' to 'end-to-end path' in a few
paragraph.

>   * Using a larger initial window should not be discussed as an
>     "option".  Basically, that is just confusing terminology.  The
>     mechanism does not require a TCP option, so I usually use
>     "mechanism" or some other word that is not already well
>     understood.
>
>   * [7] discusses measurements, not simulations.
>
> Section 3.1.3:
>
>   * Use units "cwnd > 2" should be "cwnd > 2 segments".  Check the
>     whole document for instances of this.
>
>   * "rate for the link layer." --> "rate for the network path."
>
>   * "[11] ," --> "[11],"

Fixed.

> Section 3.1.4:
>
>   * "without causing fragmentation" --> "without causing IP layer
>     fragmentation"
>
> Section 3.1.5:
>
>   * "ratio of multiple segment losses grows high" --> "probability
>     of multiple segment losses in a single window of data grows"
>
> Section 3.1.6:
>
>   * "TCP sender can then" --> "TCP sender MUST then"  (per the ECN
>     RFC)
>
> Section 3.1.7:
>
>   * Shouldn't there be a qualifier on using an initial window > 2
>     segments based on the previous text about gateways (i.e., a
>     qualifier of "if behind a gateway")?

Added the qualifier.

> Section 4:
>
>   * Nuke "and so on".  Too informal.
>
>   * "for attacks" --> "security-wise"  (I also suggest citing the
>     CCR paper from last year (I think) that outlines some of the
>     implications of using T/TCP.)
>
>   * You need to say something about Eifel at the end of the
>     paragraph like: this is promising and we should keep watching
>     it, or something to that effect (i.e., a conclusion, a group
>     action item, if you will).
>
>   * The text for DSACK says very little.  I can't even really parse
>     it.  I suggest re-working it.

Reworked as follows;

   D-SACK (Duplicated SACK), RFC2883[29], specifies how to use the SACK
   option when acknowledging duplicate segments. Using D-SACK, sender
   can know what order the segments arrived and infer more precisely
   the cause for the situations where duplicate packets received,
   including early retransmit timeout. Because the delay-jitter seen in
   the 2.5G/3G networks may cause such early retransmit timeout, this
   extension can be useful for adjusting the RTO calculation to reduce
   the case of spurious retransmissions.

  We should watch more evaluation and deployment/standardization
   status of Eifel and D-SACK in the wireless environment.

>   * "retransmission of TCP" --> "retransmission due to TCP"

Fixed.

> Section 3.1.2:
>
>   * It is not clear to me why your networks require a tighter rule
>     regarding the initial window that the general spec (RFC 2581).
>     In other words, why do you declare an initial window of 2
>     segments a MUST when the standard allows for the use of 1 or 2
>     segment?  I think your recommendation should be a SHOULD (i.e.,
>     use 2 segments unless you have a really good reason not to).

The recommendation is changed.

   Due to the fact that the delayed Ack mechanism is the standard and
   that the increased initial window option is especially effective for
   the small data transfer that is common for mobile wireless devices,
   TCP over 2.5G/3G SHOULD use initial CWND (congestion window) = 2
   segments. It MAY use CWND > 2 segments if a gateway is present. When
   applying CWND > 2 segments, it MAY also be applicable to the restart
   window.

>   * Your discussion of the larger initial window when gateways are
>     deployed is confusing.  I assume you are advocating using a
>     larger intial window on the non-Internet side of the gateway,
>     right?  This bit of text needs reworked.  Also, I would suggest
>     adding a reference to the PILC PEP document in there somewhere.

Incorporated.

   Two segments of initial congestion window size is recommended in
   RFC2581[4]. RFC2414[5] also notes consideration on use of initial
   window size of more than two. Although the increased initial
   congestion window is experimental status, there is no impact of use
   of it to the majority of the Internet if the split architecture[36]
   is deployed that terminates TCP connection between the mobile node
   and the gateway and could set the CWND > 2 segments only to the TCP
   connection to the mobile node.

> Section 3.2:
>
>   * I did not really understand the point of outlining a bunch of
>     different network types in the document.  I suggest either (a)
>     nuking this section or (b) motivating it a lot better.

For (b),  one of the authors comments as follows;

The draft applies to several wireless technologies. This being such a broad
subject, a first attempt at delimiting the scope of the document is by the
inclusion of "2.5G/3G wireless" in the title, and the further explanation in
section 2. However convenient as a label, "2.5G/3G" does not entirely
convey the type of network our recommendations apply to. No single,
simple label does, which is why we hope a few examples would go a
long way. Notice that the applicability of the document to these
technologies　is supported by the list of authors. Thus, section 3.2 may
constitute an　"applicability
statement" for the BCP, without the need for the usual separate document　to
this effect.

> Section 4:
>
>   * Limited Transmit: Why not recommend this?  The SLOW document
>     does.  It seems like the mechanism is mostly benign and may help
>     you, so why not?  There very well could be a good explanation,
>     but I guess I'd like to see it in the document since it is
>     curious that you wouldn't recommend a standards track mechanism.

Added the recommendation as follows;

3.1.3 Limited Transmit

   RFC3042[30], Limited Transmit, is extending Fast Retransmit/Fast
   Recovery for TCP connections with small congestion windows that is
   not enough to generate three duplicate acknowledgements. The
   mechanism calls for sending a new data segment in response to each
   of the first two duplicate acknowledgments that arrive at the
   sender. This mechanism is effective when congestion window size is
   small or if a large number of segments in a window are lost. This
   may reduce the retransmission due to TCP round trip timeout. As the
   discussion in Section 3.1.2, this mechanism is useful for small
   amounts of data to be transmitted. TCP over 2.5G/3G implementations
   SHOULD implement Limited Transmit.