TCPSAT Minutes
Tuesday, March 31, 1998
41st IETF, LA
Recorded by Dan Glover
Aaron Falk opened the meeting a little after 9:00am. The agenda for the
meeting included a presentation by Mark Allman on the Standard Mechanisms
draft and the Research Issues draft, a presentation by Jeff Semke on Auto
Tuning and a discussion on a suggestion to create a new draft on spoofing
led by Aaron.
Aaron expressed a hope that issues raised on the mailing list in the last
week would be discussed. The Standard Mechanisms draft is not ready for
last call, but the plan is to be ready for the end of April. Aaron
solicited more inputs for the Research Issues draft and for input on error
rate experience with forward error correction (FEC) coding.
Mark Allman gave a presentation on the status of the Standard Mechanisms
draft. The draft was in a similar state as at the DC meeting. Mark
discussed four items: 1)Beefing up the FEC portion of the document to
reflect that FEC is not a panacea and that even with a perfect satellite
link, noisy links elsewhere in the path will suffer from the long delay
feedback path, 2)Is Path MTU Discovery always a good thing for satellites?
3)Large windows have to be hand tuned on both sides of the connection, and
4)Security - are there privacy concerns with the broadcast nature of
satellites? Mark's Standard Mechanisms slides are available at:
http://gigahertz.lerc.nasa.gov/~mallman/papers/la-tcpsat1.ps
Discussion from the floor on FEC expressed a consensus view that FEC, while
helpful, is not a panacea. It is not always possible to get a perfect link
(e.g., jamming). FEC requires a design trade on bandwidth and processing
time.
Discussion from the floor on PMTU reached a consensus that PMTU should
remain in the draft. It was pointed out that at some error rate smaller
packets are better than bigger packets. Satellite channels tend to have
short bursts of errors then a period of clear transmission. If there is
one loss per window, then packet size doesn't matter. A larger packet size
opens the window faster than smaller packets. Smaller packets are more
efficient for store and forward systems. There is some "big" that is too
big. A point that was well made was that the coding design should pick the
appropriate MTU for the link and that Path MTU Discovery will find it.
There may be some times where Path MTU Discovery is not beneficial (i.e.,
it requires several hops over the satellite to discover the proper MTU).
There are some open issues with PMTU that are not limited to satellites.
Processing in the satellite system also affects the proper packet size.
Mark Allman reiterated the goal of a last call on the Standard Mechanisms
draft by the end of April. He will add a pointer to the PSC TCP
implementation Web page and some words on security.
Jeff Semke of PSC gave a brief presentation on window size auto-tuning
(eliminates the need to set TCP window size by hand) and will post pointers
on the list to more information. PSC has submitted a paper and has a
NetBSD implementation. [http://www.psc.edu/networking/auto.html]
Mark Allman then discussed the Research Issues draft. It is educational
and does not recommend any mitigations. It only covers TCP or TCP-related
mitigations and excludes application protocols and queuing algorithms.
Mark asked for volunteers to write various sections of the draft and asked
for more topics or headings that were not presently in the draft, but
should be. Mark's Research Issues slides are available at:
http://gigahertz.lerc.nasa.gov/~mallman/papers/la-tcpsat2.ps
It was pointed out from the floor that turning off delayed ACKs during slow
start or at any time is totally allowed.
Aaron Falk then led a discussion on spoofing.
Points from the discussion: Spoofing is used on satellite links and
transoceanic cables. It prevents the end user from having to tweak their
TCP. Some spoofing does not break the end-to-end semantics while other
spoofing does. A definition of spoofing is needed. Issues of reliability,
security, risks need to be addressed. Spoofing relies on information from
headers that could disappear (i.e., due to IPSec). Proxies and firewalls
can be thought of as spoofing. A proxy terminates a connection, relies on
trust, could isolate noisy environments from clean. (Aaron provided a
laser pointer for remarks from the floor noting that one always needs a
laser pointer at a satellite meeting.) Large queues in satellite routers
could be helpful. We don't want to say that spoofing is necessary. A
security advisor is needed. [Hilarie Orman has volunteered to advise on
security issues.]
There was a consensus to produce a draft outside of TCPSAT on spoofing
perhaps leading to an informational RFC. A BOF in Chicago will be
requested. [A mailing list to discuss spoofing has been set up with
instructions available at http://tcppep.lerc.nasa.gov/tcppep/ ]
Aaron Falk adjourned the meeting at 10:20am.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:42 EST