The calm before the storm

Last week, Pittsburgh hosted the 48th IETF meeting. The flow of RFCs slowed but didn't stop entirely during the meeting, as Pete Loshin explains.

By Pete Loshin | Posted Aug 11, 2000
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

IETF Corner by Pete Loshin

Pittsburgh is a happening place: Geographically, it is located at the confluence of the Allegheny, Monongahela, and Ohio Rivers. As such, it is a city of bridges. Historically, it has a working class heritage as a center of steel and industry, tarnished over the years as industry waned and polished again by its intellectual capital. Much of Pittsburgh's recent boom has been fueled by the Internet, stoked by students at Pittsburgh's world-class universities. Pittsburgh was host last week to the 48th IETF meeting in the heart of the vibrant downtown. Unfortunately, your interlocutor was unable to attend, so I'm also unable to pass along any tidbits about what went on--we must all wait for publication of minutes and other reports from attendees.

As so often happens, the process of approving and publishing RFCs grinds almost to a halt as the members of the IETF and IESG gird their loins for the IETF meetings; we should see a resumption in the processes before too long, but in the meantime only a handful of RFCs were announced and a single working group action was taken. Not much else happened, officially, outside of the halls of the David L. Lawrence Convention Center (not to mention the pubs and other meeting places frequented by IETFers) in Pittsburgh.

If you don't want to miss the next IETF meetings, mark your calendars now: The 49th IETF will be held December 11-15, 2000, in San Diego, hosted by Qualcomm Inc. and Cisco Systems Inc.; the 50th IETF will be held March 18-23, 2001 in Minneapolis, Minn., hosted by Lucent Technologies Inc. And if you're really planning ahead, pencil in the date for the 51st IETF, tentatively to be held August 5-10, 2001, in London, England, and hosted by British Telecom PLC.

New RFCs

Table 1 shows the meager offering of new RFCs from the past couple of weeks. As I mentioned, the pickings are quite slim--just two Proposed Standards and three Informationals.

First, the Proposed Standards. Probably of greatest interest is RFC 2883, "An Extension to the Selective Acknowledgement (SACK) Option for TCP." The original specification for the Transmission Control Protocol (TCP) had a serious flaw: When a recipient didn't get some data, it had to notify the sender, and in most cases the sender had to retransmit all data sent after the lost bits--even if the recipient had already received that data. For instance, a transmission might be going along just great, and then one packet would be dropped (or delayed enough to make the recipient think it was dropped). The recipient would indicate to the sender that a TCP segment was missing. The way TCP was defined, the sender could specify only the last segment received before the missing segment--meaning that all segments after that one would have to be retransmitted. There was no mechanism for the recipient to tell the sender that everything came through fine, except for the third segment (for example) in a 500-segment sequence.

RFC 2018, "TCP Selective Acknowledgement Options," changed that situation by defining the Selective Acknowledgment (SACK) mechanism. And RFC 2883 builds on RFC 2018 by defining an extension of the SACK option for TCP that lets recipients notify senders when duplicate segments have been received. As the RFC suggests, "This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet." The sender can take advantage of this knowledge by using it to operate more robustly in an "environment of reordered packets, ACK loss, packet replication, and/or early retransmit timeouts."

The other Proposed Standard, RFC 2878, "PPP Bridging Control Protocol (BCP)," specifies "the Network Control Protocol for establishing and configuring Remote Bridging for PPP links." As an update to RFC 1638 (of the same name), RFC 2878 makes relatively few changes, mostly updating the specification to reflect current practices and IEEE standards (specifically, the 802.1Q VLAN standards).

The Informationals this time around are a slightly mixed bag of moderately interesting documents. The most important, especially for ISPs, is RFC 2881, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model," which lays the groundwork for a Network Access Server (NAS) model to succeed the RADIUS model.

Another RADIUS-related document, RFC 2882, "Network Access Servers Requirements: Extended RADIUS Practices," goes beyond the RFCs to document how RADIUS is actually implemented and used in real-world products. This one is particularly interesting in that, in some cases, it provides the only readily accessible information about these proprietary implementations.

Finally, RFC 2884, "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks," provides an in-depth report on a mechanism for reporting congestion. The bottom line: It works. ECN works by having routers notify the sender when a packet is dropped instead of just silently dropping them when the router is under heavy load. Once notified, the sender can throttle back the transmission rate so it won't have to do a lot of waiting around for ACKs and then retransmitting the data that was dropped on the floor by the overworked router. RFC authors Jamal Hadi Salim from Nortel Networks and Uvaiz Ahmed from Carleton University's Dept. of Systems and Computer Engineering conclude that ECN improved performance for both bulk transmission and transactional transmissions.

Document, protocol, and Working Group Actions

The IESG made only two announcements this past two weeks. One was a last call, and the other announced the formation of a new working group: the Source-Specific Multicast (SSM) working group. SSM intends "to standardize and clearly elucidate the definition of source-specific multicast in such a way as to provide unambiguous semantics to the designers of the protocols and host interfaces used in conjunction with source-specific multicast." In other words, SSM will be clarifying and updating multicast specifications. Its charter proclaims that it is intended "to be a short-lived, highly-focused working group," so look for fast action from these folks.

What's Next

Next time, look out--I should have all the latest and greatest on what went on in Pittsburgh. If you read the general IETF mailing list, you know that a lot of thought was given to elevators: how you can tell you're sharing one with geeks (they comment on the primeness or non-primeness of the floor numbers lit on the request panel), and how scalable and secure they are. More to the point, the increasing use of wireless network cards is a big win: They allow attendees to check e-mail without leaving the session rooms. Check back here in two weeks for more substantive results. //

Pete Loshin has been writing about IP networking since 1988, including 20 books about networking, the Internet, and Internet standards. The founder of, Pete frequently consults on Internet protocol issues.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter