TCPIMPL Meeting Minutes
December 9, 1998

Report by: Joe Touch (touch@isi.edu), Mark Allman
           (mallman@lerc.nasa.gov), Vern Paxson (vern@ee.lbl.gov)


The status of WG documents was reviewed, as follows:

    Known Problems document is now with the AD for submission to
    the IESG for publication as Informational.

    NewReno draft is in WG last call period.  No major comments on
    this document to date.  The plan is to submit it for Experimental
    at the same time that 2001.bis goes for Proposed.

    2001.bis is under going several minor changes in response to
    comments during the WG last call period.

    The re-start document is under heavy revision.

Peter Ford led a short discussion on raising the initial window size
in 2001.bis (to be a proposed standard, as compared to RFC 2414
which is an experimental RFC that raises the initial congestion
window) from 1 segment to "up to 2 segments".  The basic argument in
favor was that when developing RFC 2414, the only aspects of it that
the WG had found merited further experimentation were the larger
windows of 3 or 4 segments; support for 2 segments had been strong.
In the subsequent discussion at the meeting, several people
commented that they thought this was a good idea, nobody disagreed
with the change, and the sense of the room was one of enthused
support.  The issue will also be discussed on the mailing list.

Jamshid Mahdavi presented a short report on the usefulness of the WG
documents for debugging TCP stacks.  In addition, he outlined two
new problems: slow start being too aggressive and RTO that were not
long enough.  He also suggested that the known problems document
would benefit from identifying problems as either "sender" or
"receiver" bugs.  These were judged as probably appropriate for an
update of the known problems document, as the current version is now
already with the AD.

Joe Touch outlined a new algorithm for preventing TCP from sending
large bursts into the network.  The algorithm needs to be documented
in an internet-draft before the group considers it further.

Finally, Kevin Lahey led a short discussion on Path MTU Discovery
issues.  Kevin outlined several issues with path MTU discovery:

    BUGS
        using PMTU to determine MSS
        determining MTU on per-conn basis
    ACK frequency
        every 2 packets
        dynamic determination of segment size
    multihoming
    black-hole detection

Kevin outlined that an implementation can be within the
specification, but still not optimal.  First, some implementations
reuse PMTU to determine MSS. For example, if you reopen a connection
to the same place and reuse the MTU, you won't probe for higher MTU
sizes.  Second, some implementations rediscover the PMTU for each
connection, which can induce high amounts of ICMP traffic and be
inefficient, esp. for systems with high numbers of short connections
(e.g. HTTP 1.0).

Kevin then outlined problems that arise when determining when to
send a delayed ACK and how path MTU discovery complicates the
situation.  Consider two FDDI hosts, where the rings are
interconnected by an ethernet. The MSS is 4KB, and the receiver ACKs
after 2 MSS's. PMTU squeezes the packets down to 1.5 KB, and
therefore, the ACK really ACKs 6 packets, not 2. Some systems solve
this by ACKing every other packet, rather than for 2 MSS's. Others
determine the ACK frequency using per-connection information.

The problems caused by multihomed hosts were then outlined.
Consider a host with multiple interfaces with different MTUs. That
host should advertise the largest MTU available, so that if the path
to that host changes, connections can take advantage of the largest
PMTU available.

Finally, Kevin outlined problems caused by black holes.  RFC 1435
first mentions it - some routers suppress the "FRAGMENTATION NEEDED"
ICMP reply, e.g., misconfigured routers or firewalls. The result
looks like a black-hole - full-size packets just get lost, but pings
and other small packets work fine. In this case, PMTU just freezes.
There is no description of how to handle this - there is one
implementation of a check timer at the upper layer protocol, but no
generalized description of how to solve the problem. We need a spec
to do this.

A discussion ensued about whether the WG should generate a document
on this topic.  Also, the floor was opened for other PMTU
problems/issues.  The chairs indicated that they would like to see a
document on some of these subtle problems.  However, the document
needed to be expedited.  Also, it was noted that this topic is
slightly out of our charter and therefore, the AD's approval would
be needed before officially working on this topic.  It was also
noted that IPv6 requires PMTU discovery and the ipng WG is having
some related discussions, but has not yet solved the problem.

The consensus of the room was that a document on "experience with
PMTU" would be useful & appropriate, with the chairs specifying that
they would require a draft by January since the WG has wound down.

The meeting was adjourned noting that we do not plan to hold any
further face-to-face meetings, but that the mailing list will remain
active.