(19) United States
`(12) Patent Application Publication (10) Pub. N0.I US 2007/0226375 A1
`(43) Pub. Date:
`Sep. 27, 2007
`Chu et al.
`
`US 20070226375Al
`
`(54) PLUG-IN ARCHITECTURE FOR A
`NETWORK STACK IN AN OPERATING
`SYSTEM
`
`(76)
`
`Inventors: Hsiao-Keng J. Chu, Palo Alto, CA
`(US); Darrin P. Johnson, Mountain
`View, CA (U S); Ka-Cheong Poon,
`Kowloon (HK)
`
`Correspondence Address:
`SUN MICROSYSTEMS INC.
`C/O PARK, VAUGHAN & FLEMING LLP
`2820 FIFTH STREET
`DAVIS, CA 95618-7759 (US)
`
`(21)
`
`(22)
`
`Appl. No.:
`
`11/388,438
`
`Filed:
`
`Mar. 23, 2006
`
`Publication Classi?cation
`
`(51) Int. Cl.
`(2006.01)
`G06F 15/16
`(52) us. c1. ......................... ..709/250; 709/228; 709/227
`
`(57)
`
`ABSTRACT
`
`One embodiment of the present invention provides a plug-in
`architecture for a network stack in an operating system. The
`network stack includes a set of functions con?gured to
`modify a set of parameters that are likely to change based on
`the network environment. The architecture includes a plug
`in framework within the network stack that allows the set of
`functions to be dynamically changed in order to change the
`TCP behavior of the network stack to suit the network
`environment.
`
`COMPUTER SYSTEM
`102
`
`COMPUTER SYSTEM
`1 12
`
`SENDER
`APPLICATION
`104
`
`_
`
`‘7
`SOCKET API
`106
`
`V
`
`TCP LAYER
`
`IP LAYER
`
`LINK LAYER
`
`l
`|
`I
`I
`
`l
`I
`|
`I
`l
`l
`l
`'
`I
`I
`l
`l
`I
`
`I
`r
`
`>
`
`NETWORK
`STACK <
`108
`
`l
`|
`I
`I
`
`l
`l
`|
`I
`I
`l
`l
`I
`I
`I
`l
`I
`I
`
`RECEIVING
`APPLICATION
`114
`
`I
`SOCKET API
`106
`I
`
`TCP LAYER
`
`IP LAYER
`
`LINK LAYER
`
`l
`I
`I
`
`l
`I
`I
`l
`l
`I
`'
`I
`I
`:
`
`I
`|
`
`l
`
`J
`
`i 'm'TmJ
`
`NETWORK LINK '
`110
`
`AKAMAI
`EXHIBIT 1004
`
`

`
`Patent Application Publication Sep. 27, 2007 Sheet 1 0f 3
`
`US 2007/0226375 A1
`
`COMPUTER SYSTEM
`102
`
`COMPUTER SYSTEM
`112
`
`RECEIVING
`APPLICATION
`114
`
`SOCKET API
`
`1
`106 I
`
`TCP LAYER
`
`IP LAYER
`
`LINK LAYER
`
`a
`
`SENDER
`APPLICATION
`104
`
`V
`
`SOCKET API
`106
`
`TCP LAYER
`
`lP LAYER
`
`LINK LAYER
`
`>
`
`NETWORK
`STACK
`108
`
`4
`
`NETWORK LINK‘
`110
`
`FIG. 1
`
`

`
`Patent Application Publication Sep. 27, 2007 Sheet 2 0f 3
`
`US 2007/0226375 A1
`
`TIMER
`NOTIFICATION
`212
`
`ACKNOWLEDGEMENTS
`
`.
`
`210
`
`TCP TRANSMIT
`PROCESSING
`202
`
`TCP RECEIVE
`PROCESSING
`204
`
`TRANSMIT
`CALL-BACK
`216
`
`PLUG-IN
`FUNCT|ON(S)
`206
`
`TRANSMITTED PACKETS
`20a
`
`FIG. 2
`
`

`
`Patent Application Publication Sep. 27, 2007 Sheet 3 0f 3
`
`US 2007/0226375 A1
`
`DETERMINE A NEED FOR _
`CHANGING THETCPgBEHAVIOR
`OF A NETWORK CONNECTION
`302
`
`DISABLE A PORTION OF THE
`NETWORK STACK TO PUT THE
`NETWORK CONNECTION‘ INTO A
`QUIESCENT STATE
`304
`
`CHANGE THE FUNCTION POINTER
`FOR THE FUNCTION ASSOCIATED
`WITH THE TOP BEHAVIOR TO
`POINT TO'THE NEW FUNCTION
`306
`
`RE-ENABLE THE PORTION OF THE
`' NETWORK STACK TO RETURN
`THE- NETWORK CONNECTION TO
`AN ACTIVE STATE
`308
`
`FIG. '3
`
`

`
`US 2007/0226375 A1
`
`Sep. 27, 2007
`
`PLUG-IN ARCHITECTURE FOR A NETWORK
`STACK IN AN OPERATING SYSTEM
`
`RELATED APPLICATION
`
`[0001] The subject matter of this application is related to
`the subject matter in a co-pending non-provisional applica
`tion by the same inventors as the instant application and ?led
`on the same day as the instant application entitled, “Method
`and Apparatus for Dynamically Changing the TCP Behavior
`of a Network Connection,” having serial number TO BE
`ASSIGNED, and ?ling date TO BE ASSIGNED (Attorney
`Docket No. SUN06-0663).
`
`BACKGROUND
`
`[0002] 1. Field of the Invention
`[0003] The present invention generally relates to computer
`netWorks. More speci?cally, the present invention relates to
`a plug-in architecture for a netWork stack in an operating
`system.
`[0004] 2. RelatedArt
`[0005] The transmission control protocol (TCP) is part of
`the core Internet protocol Which is used to transfer data
`betWeen computing devices. The goal of TCP is to transfer
`data from an application on a computing device through a
`shared netWork resource to a second device as quickly,
`efficiently, and reliably as possible, despite potential con
`tention and congestion.
`[0006] While the basic operation of TCP has not changed
`dramatically since the initial publication of the standard in
`1981, the protocol has been forced to evolve in response to
`changing netWork conditions such as neW link types (e.g.,
`Wireless netWorks) and higher bandWidth Wired netWorks.
`Substantial ongoing research on congestion control and
`avoidance has resulted in numerous TCP congestion control
`techniques, such as Reno, NeW Reno, Vegas, HS-TCP, Fast
`TCP, S-TCP, and Bic-TCP. HoWever, such congestion con
`trol techniques add substantial complexity to TCP and the
`netWork stack. Furthermore, end-to-end links can traverse
`numerous netWorks With diverse characteristics, and no
`single congestion control approach encompasses the Wide
`range of modern netWorks.
`
`[0007] Hence, What is needed are architectures and meth
`ods that facilitate congestion control for TCP Without the
`limitations of existing approaches.
`
`SUMMARY
`
`[0008] One embodiment of the present invention provides
`a plug-in architecture for a netWork stack in an operating
`system. The netWork stack includes a set of functions
`con?gured to modify a set of parameters that are likely to
`change based on the netWork environment. The architecture
`includes a plug-in frameWork Within the netWork stack that
`alloWs the set of functions to be dynamically changed in
`order to change the TCP behavior of the netWork stack to
`suit the netWork environment.
`
`[0009] In a variation on this embodiment, the parameters
`include:
`
`[0010] a round-trip time (“RTT”), Which is the time it
`takes a data packet to travel from the ?rst computer
`system to the second computer system and back;
`
`[0011] a congestion WindoW (“cWnd”), Which speci?es
`the number of data packets that can be transmitted
`Without having received corresponding acknoWledge
`ment packets; and/or
`
`[0012] a sloW-start threshold (“ssthresh”), Which deter
`mines hoW the siZe of the congestion WindoW
`increases.
`
`[0013] In a variation on this embodiment, changing the set
`of functions changes the transmit and receive characteristics
`of the netWork stack, thereby changing the congestion
`control technique for the netWork stack.
`
`[0014] In a further variation, the set of functions are
`triggered by events that include:
`
`[0015] the receipt of a positive acknoWledgement indi
`cating that a packet Was received;
`[0016] the receipt of negative acknoWledgements indi
`cating that packets may have been lost;
`
`the expiration of a timer;
`
`the elapse of a round-trip time interval;
`
`[0017] the receipt of a selective acknoWledgement that
`identi?es received packets;
`[0018]
`[0019]
`[0020] a call-back occurring either before or after a
`packet transmission; and
`[0021] the receipt of an explicit congestion noti?cation
`(ECN).
`[0022] In a further variation, triggering an event prompts
`the set of functions to update the set of parameters.
`
`[0023] In a variation on this embodiment, the netWork
`stack maintains a set of generic state information, and the set
`of functions maintains a set of state separate from the set of
`generic state information. The set of functions can access the
`set of generic state information.
`
`[0024] In a variation on this embodiment, the set of
`functions is implemented as a dynamically loadable kernel
`module.
`
`[0025] In a variation on this embodiment, changing the set
`of functions alloWs the netWork stack to dynamically change
`TCP behavior and thereby transmit ef?ciently across diverse
`and changing netWork environments.
`
`BRIEF DESCRIPTION OF THE FIGURES
`
`[0026] FIG. 1 illustrates tWo computer systems commu
`nicating over a netWork link in accordance With an embodi
`ment of the present invention.
`
`[0027] FIG. 2 illustrates TCP transmit and receive inter
`actions in accordance With an embodiment of the present
`invention.
`
`[0028] FIG. 3 presents a How chart illustrating the process
`of changing the TCP behavior of a netWork connection in
`accordance With an embodiment of the present invention.
`
`DETAILED DESCRIPTION
`[0029] The folloWing description is presented to enable
`any person skilled in the art to make and use the invention,
`and is provided in the context of a particular application and
`
`

`
`US 2007/0226375 A1
`
`Sep. 27, 2007
`
`its requirements. Various modi?cations to the disclosed
`embodiments Will be readily apparent to those skilled in the
`art, and the general principles de?ned herein may be applied
`to other embodiments and applications Without departing
`from the spirit and scope of the present invention. Thus, the
`present invention is not limited to the embodiments shoWn,
`but is to be accorded the Widest scope consistent With the
`claims.
`
`[0030] The data structures and code described in this
`detailed description are typically stored on a computer
`readable storage medium, Which may be any device or
`medium that can store code and/or data for use by a
`computer system. This includes, but is not limited to,
`magnetic and optical storage devices such as disk drives,
`magnetic tape, CDs (compact discs), DVDs (digital versatile
`discs or digital video discs), or any device capable of storing
`data usable by a computer system.
`TCP Congestion Control
`
`[0031] FIG. 1 illustrates tWo computer systems commu
`nicating over a netWork link 110. A sender application 104
`in the sending computer system 102 uses a socket API 106
`to pass data to a netWork stack 108, Which packetiZes the
`data and sends it over a netWork link 110 to a receiving
`computer system 112. The netWork stack 108 on the receiv
`ing computer system 112 processes the packets and passes
`them up to the receiving application 114 through the socket
`API 106.
`
`[0032] The TCP layer comprises an important part of the
`netWork stack 108. The core of the TCP protocol is based on
`a set of parameters that together determine a set of data
`packets, a timeframe in Which they Will be transmitted from
`the sender side, and hoW acknoWledgements Will be gener
`ated on the receiving side. The sending side constantly
`recalculates the set of parameters based on feedback from,
`for instance, acknoWledgement packets and local timers, in
`order to decide Which data to send or resend, and When.
`Important parameters include:
`[0033] “RTT”, the round-trip time it takes a data packet
`to travel from the sender to the receiver;
`[0034] “cWnd,” the siZe of the congestion WindoW,
`Which speci?es the number of data packets that can be
`transmitted Without having received corresponding
`acknoWledgement packets; and
`[0035] “ssthresh,” the sloW-start threshold, Which deter
`mines hoW the siZe of the congestion WindoW
`increases.
`
`The receiver side, meanWhile, decides When to generate
`either positive, negative, or selective acknoWledge
`ments.
`
`[0036] TCP strives to maximize the utiliZation of the
`available netWork bandWidth in a “fair” manner (i.e. friendly
`to other TCP traffic), while avoiding, or otherWise quickly
`recovering from, netWork congestion. Achieving this goal is
`dif?cult given the Wide diversity of modem netWorking
`technologies. The effectiveness of congestion control in
`arti?cial and production environments is: often sorely tested
`by factors such as the distance betWeen sender and receiver,
`WindoW siZes, the number of streams, netWork con?gura
`tion, load, varying drop rates, link reliability, etc. While
`many different TCP techniques have been proposed over the
`
`years, including but not limited to Reno, NeW Reno, Vegas,
`HS-TCP, S-TCP, Bic-TCP, Cubic, Fast-TCP, and TCP-West
`Wood, no technique has been found that performs best across
`all instances.
`[0037] Traditionally, the congestion-control technique is
`hard-Wired in the TCP implementation, and can only be
`changed by compiling a second operating system kernel
`With a neW technique, shutting doWn the system, and replac
`ing the current operating system kernel. Since no single,
`de?nitive solution exists nor seems to be forthcoming, a
`traditional, netWork-stack architecture With one hard-Wired
`TCP congestion-control technique Will not provide a pro
`duction solution nor keep up With future advances in TCP
`research and the possible proliferation of TCP techniques.
`[0038] The present invention extends TCP using a plug-in
`architecture for the netWork stack of an operating system.
`A Plug-In Architecture for TCP Congestion Control
`[0039] The present invention extends existing netWork
`stacks (including stacks deployed in kernel space, user
`space, and/or in TCP ol?oad engines) to alloW core functions
`of the TCP congestion control system to be changed easily
`and dynamically. While many portions of the TCP imple
`mentation contribute to TCP dynamics, only a subset of the
`implementation is likely to still evolve. One such area still
`seeing signi?cant changes is transmission-side congestion
`avoidance.
`
`the receipt of neW data to be sent;
`
`[0040] In one embodiment of the present invention, a
`subset of the TCP transmit functionality becomes a sWap
`pable plug-in, While the standardiZed and unchanging por
`tion of the TCP layer remains hard-Wired. The system enters
`the sWappable portion Whenever an event is encountered that
`triggers a recomputation of congestion parameters, for
`instance cWnd, ssthresh, and RTT. Such triggers for the TCP
`sender side include:
`[0041]
`[0042] the receipt of a positive acknoWledgement indi
`cating that a packet Was received;
`[0043] the receipt of negative acknoWledgements indi
`cating that packets may have been lost;
`[0044] the receipt of a selective acknoWledgement that
`identi?es a received packet;
`[0045]
`[0046]
`[0047] a call-back occurring either before or after a
`packet transmission or re-transmission; and
`
`the expiration of a timer;
`
`the elapse of a round-trip time interval;
`
`[0048] the receipt of an explicit congestion noti?cation
`(ECN).
`The plug-in module includes a set of functions that are
`invoked in response to the above events. These func
`tions can be given access to ?elds from the TCP layer,
`such as the TCP control block and headers of acknoWl
`edgement packets, thereby alloWing the plug-in to Work
`directly with the raw TCP parameters. Allowing this
`type of access, instead of creating an abstraction on top
`of TCP, enables all approaches of congestion avoid
`ance, including loss-based and delay-based approaches.
`The main output from these functions is a set of
`
`

`
`US 2007/0226375 A1
`
`Sep. 27, 2007
`
`recomputed parameters (eg cwnd, ssthresh, RTT),
`which are then fed back into the hard-wired portion of
`the TCP implementation to continue execution.
`
`[0049] FIG. 2 illustrates typical TCP transmit and receive
`interactions in the system. In one embodiment of the present
`invention, the TCP transmit processing system 202 includes
`a set of plug-in functions 206 which affect the characteristics
`and timing of the packets transmitted 208 by the sender. The
`TCP receive processing 204 on the receiving computer
`system in turn returns positive, negative, or selective
`acknowledgements 210. The TCP transmit processing 202
`takes into account these acknowledgements 210, along with
`other events such as timer noti?cations 212, ECNs 214, and
`transmit call-backs 216 prompted by packet transmissions or
`re-transmissions.
`
`[0050] The plug-in architecture allows the system to
`switch between different congestion avoidance techniques.
`Each technique uses a different approach, and may therefore
`maintain a different set of internal state. For instance, a
`delay-based technique such as Fast-TCP may track average
`queuing delay as well as minimum and biased RTTs, while
`TCP-Westwood gleans data from successive acknowledge
`ment packets to compute an eligible rate estimate (ERE).
`Alternatively, High-Speed TCP (HS-TCP), a loss-based
`technique, keeps an internal table of congestion window
`siZes (i.e. a table for “a (cwnd)” and “b(cwnd)”). These
`internal parameters are typically not visible outside the
`plug-in, but can be used by the plug-in to adjust key
`parameters that control TCP behavior. The system can
`effectively give full control of TCP behavior to the plug-in
`by only allowing control parameters to be changed in the
`plugged-in functions.
`
`[0051] In general, given the changing nature (e.g. increas
`ing bandwidth, distances, topology variations, production
`requirements, etc) of production and experimental networks,
`allowing TCP behavior to be easily replaced provides sig
`ni?cant advantages over the previous hard-wired approach,
`which provides only limited capability. Allowing the TCP
`behavior to be easily modi?ed, either manually or dynami
`cally, provides an opportunity to tune network performance
`of production networks as well as provide a ?exible way to
`explore, implement, and test new congestion control tech
`niques.
`
`[0052] In one embodiment of the present invention, the
`plug-in functionality is implemented using a dynamically
`loaded kernel module that can be loaded or unloaded both at
`system boot-time as well as when the system is active.
`
`Per-Connection TCP Congestion Control
`
`[0053] While a plug-in architecture for TCP allows TCP
`behavior to be changed at the system level, each network
`connection may encounter different conditions based on the
`destination or other factors, so a more ideal solution allows
`multiple techniques to be applied simultaneously on the
`computer system.
`
`[0054] One embodiment of the present invention provides
`network resource- and bandwidth-control by extending the
`plug-in architecture to allow different TCP behaviors to be
`plugged-in on a per-connection basis. The system maintains
`a vector of function pointers that point to the chosen TCP
`technique for each connection. Depending on system policy,
`
`the appropriate technique for a connection may be chosen at
`a very ?ne granularity, and vary dynamically, based on:
`[0055]
`user input or speci?cation of priority;
`application input or preference;
`[0056]
`[0057]
`an application type;
`system policy;
`[0058]
`[0059] the source and/or destination port numbers used
`by the network connection;
`[0060] the source and/or destination Internet Protocol
`(IP) addresses of the network connection;
`[0061]
`the protocol used by the network connection;
`[0062] the characteristics of the network connection,
`including latency, bandwidth, loss-rate, and traf?c char
`acteristics;
`[0063]
`the service provided by the network connection;
`[0064]
`cached path characteristics from past connec
`tions;
`[0065] the location of the computer system and the
`second computer system; or
`[0066]
`For instance, a connection to a local wireless IP address
`may need different TCP behavior than a streaming
`video application on a ?xed network transferring real
`time video from a remote server. The system can
`maintain a list of candidate functions for TCP behavior
`from which the application or user chooses, or in a
`further embodiment, privileged users can de?ne and
`plug-in their own functions, subject to a control policy
`that deters abusive network behavior.
`
`any combination of the above.
`
`[0067] FIG. 3 presents a ?ow chart illustrating the process
`of changing the TCP behavior of a network connection. The
`system ?rst determines or is noti?ed of a need for changing
`the TCP behavior of a network connection (step 302). In
`response, the system disables a relevant portion of the
`network stack in order to put the network connection into a
`quiescent state (step 304). Then, the system changes the
`function pointer for the function associated with the TCP
`behavior to point to a new function with the desired behavior
`(step 306). Finally, the system re-enables the corresponding
`portion of the network stack to return the network connec
`tion to an active state (step 308). Note that since this switch
`occurs quickly enough, and the system typically has capac
`ity to buffer packets, there is effectively no interruption of
`network service. Relevant state information or other knowl
`edge can be retained for the new function, or alternatively
`the new function may re-compute important parameters
`from scratch after the swap.
`[0068] Fine-grained per-connection control of TCP behav
`ior enables additional possibilities not available with a
`traditional hard-wired TCP layer. Traditionally, quality-of
`service (QoS) and bandwidth control occur outside of the
`transport layer, for instance at the IP layer or in the network.
`While this approach is less intrusive to the network stack, it
`also has many limitations, e.g. providing end-to-end QoS in
`the network typically requires the con?guration and coop
`eration of all of the switches and routers the traf?c ?ows
`through, which is often infeasible. A plug-in function for a
`
`

`
`US 2007/0226375 A1
`
`Sep. 27, 2007
`
`connection can provide a level of QoS and bandwidth
`control directly inside the TCP layer, thereby taking advan
`tage of knowledge that is difficult to obtain from outside of
`the transport layer. For instance, in a traditional system, an
`attempt to throttle-doWn transmission might be interpreted
`as a sign of congestion and/or time-out, and prompt undes
`ired re-transmission. The traditional approach of performing
`resource control and bandWidth management outside of the
`transport layer at a ?ne granularity also incurs heavy pro
`cessing overhead in parsing headers and maintaining state
`on a per-?oW basis. In the present invention, such capabili
`ties can be added to the TCP behavior using a plug-in and
`handled appropriately.
`[0069] The plug-in approach also enables employing an
`aggressive, special-purpose technique in a controlled net
`Work environment. For instance, a server in a data center
`With a Well-controlled traffic pattern or Well-tuned queuing
`model might deploy a non-compliant congestion control
`technique that alloWs packets to be sent Without sloW-start or
`any bandWidth throttling. This technique could be useful, for
`example, to eliminate the overhead of congestion control for
`connections that transfer data betWeen tWo servers on a
`dedicated netWork link, or to expedite connections that
`exchange cluster membership heartbeat messages Within the
`data center. Previously, such service variation either Was not
`possible, or Would require multiple servers.
`[0070] Finally, per-connection tuning can also be used to
`deploy and test experimental TCP behaviors on a limited set
`of TCP connections on a production server Without exposing
`other, normal operations on the server to the riskier neW
`behavior.
`
`[0071] In summary, the present invention extends TCP
`behavior using a plug-in architecture. This architecture
`alloWs TCP behavior to be tuned on a per-connection basis,
`thereby enabling the core functions of the TCP congestion
`control system to adapt to changing netWork conditions and
`improving the speed and efficiency of data transfers.
`[0072] The foregoing descriptions of embodiments of the
`present invention have been presented only for purposes of
`illustration and description. They are not intended to be
`exhaustive or to limit the present invention to the forms
`disclosed. Accordingly, many modi?cations and variations
`Will be apparent to practitioners skilled in the art. Addition
`ally, the above disclosure is not intended to limit the present
`invention. The scope of the present invention is de?ned by
`the appended claims.
`
`What is claimed is:
`1. A plug-in architecture for a netWork stack in an
`operating system, comprising:
`the netWork stack;
`
`a set of functions in the netWork stack con?gured to
`modify a set of parameters identi?ed as likely to change
`based on the netWork environment; and
`
`a plug-in frameWork Within the netWork stack con?gured
`to dynamically change the set of functions that change
`the set of parameters and thereby change the TCP
`behavior of the netWork stack to suit the netWork
`environment.
`2. The plug-in architecture of claim 1, Wherein the set of
`parameters includes:
`
`a round-trip time (“RTT”), Which is the time it takes a data
`packet to travel from the ?rst computer system to the
`second computer system and back;
`
`a congestion WindoW (“cWnd”), Which speci?es the num
`ber of data packets that can be transmitted Without
`having received corresponding acknoWledgement
`packets; and/or
`
`a sloW-start threshold (“ssthresh”), Which determines hoW
`the siZe of the congestion WindoW increases.
`3. The plug-in architecture of claim 1, Wherein changing
`the set of functions changes the transmit and receive char
`acteristics of the netWork stack; and
`
`Wherein changing the transmit and receive characteristics
`of the netWork stack changes the congestion-control
`technique for the netWork stack.
`4. The plug-in architecture of claim 3, Wherein the set of
`functions are triggered by events including:
`the receipt of a positive acknoWledgement indicating that
`a packet Was received;
`the receipt of negative acknoWledgements indicating that
`packets may have been lost;
`
`the receipt of a selective acknoWledgement that identi?es
`a received packet;
`
`the expiration of a timer;
`
`the elapse of a round-trip time interval;
`
`a call-back occurring either before or after a packet
`transmission; and
`the receipt of an explicit congestion noti?cation (ECN).
`5. The plug-in architecture of claim 4, Wherein triggering
`an event prompts the set of functions to update the set of
`parameters.
`6. The plug-in architecture of claim 1,
`
`Wherein the netWork stack maintains a set of generic state
`information;
`Wherein the set of functions maintains a separate set of
`state from the set of generic state information; and
`
`Wherein the set of functions can access the set of generic
`state information.
`7. The plug-in architecture of claim 1, Wherein the set of
`functions is implemented as a dynamically loadable kernel
`module.
`8. The plug-in architecture of claim 1, Wherein changing
`the set of functions alloWs the netWork stack to dynamically
`change TCP behavior and thereby transmit ef?ciently across
`diverse and changing netWork environments.
`9. A computer-readable storage medium storing instruc
`tions that When executed by a computer provide a plug-in
`architecture for a netWork stack in an operating system,
`Wherein the netWork stack comprises:
`
`the netWork stack;
`
`a set of functions in the netWork stack con?gured to
`modify a set of parameters identi?ed as likely to change
`based on the netWork environment; and
`
`a plug-in frameWork Within the netWork stack con?gured
`to dynamically change the set of functions that change
`
`

`
`US 2007/0226375 Al
`
`Sep. 27, 2007
`
`the set of parameters and thereby change the TCP
`behavior of the network stack to suit the network
`environment.
`10. The computer-readable storage medium of claim 9,
`wherein the set of parameters includes:
`
`a round-trip time (“RTT”), which is the time it takes a data
`packet to travel from the ?rst computer system to the
`second computer system and back;
`a congestion window (“cwn ”), which speci?es the num
`ber of data packets that can be transmitted without
`having received corresponding acknowledgement
`packets; and/or
`
`a slow-start threshold (“ssthresh”), which determines how
`the siZe of the congestion window increases.
`11. The computer-readable storage medium of claim 9,
`wherein changing the set of functions changes the trans
`mit and receive characteristics of the network stack;
`and
`
`wherein changing the transmit and receive characteristics
`of the network stack changes the congestion-control
`technique for the network stack.
`12. The computer-readable storage medium of claim 11,
`wherein the set of functions are triggered by events includ
`ing:
`the receipt of a positive acknowledgement indicating that
`a packet was received;
`the receipt of negative acknowledgements indicating that
`packets may have been lost;
`the receipt of a selective acknowledgement that identi?es
`a received packet;
`
`the expiration of a timer;
`the elapse of a round-trip time interval;
`
`a call-back occurring either before or after a packet
`transmission; and
`the receipt of an explicit congestion noti?cation (ECN).
`13. The computer-readable storage medium of claim 12,
`wherein triggering an event prompts the set of functions to
`update the set of parameters.
`14. The computer-readable storage medium of claim 9,
`
`wherein the network stack maintains a set of generic state
`information;
`wherein the set of functions maintains a separate set of
`state from the set of generic state information; and
`
`wherein the set of functions can access the set of generic
`state information.
`15. The computer-readable storage medium of claim 9,
`wherein the set of functions is implemented as a dynami
`cally loadable kernel module.
`
`16. The computer-readable storage medium of claim 9,
`wherein changing the set of functions allows the network
`stack to dynamically change TCP behavior and thereby
`transmit ef?ciently across diverse and changing network
`environments.
`17. A computer system that includes:
`
`a network stack;
`
`a set of functions in the network stack con?gured to
`modify a set of parameters identi?ed as likely to change
`based on the network environment; and
`
`a plug-in framework within the network stack con?gured
`to dynamically change the set of functions that change
`the set of parameters and thereby change the TCP
`behavior of the network stack to suit the network
`environment.
`18. The computer system of claim 17, wherein the set of
`parameters includes:
`
`a round-trip time (“RTT”), which is the time it takes a data
`packet to travel from the ?rst computer system to the
`second computer system and back;
`a congestion window (“cwnd”), which speci?es the num
`ber of data packets that can be transmitted without
`having received corresponding acknowledgement
`packets; and/or
`
`a slow-start threshold (“ssthresh”), which determines how
`the siZe of the congestion window increases.
`19. The computer system of claim 17,
`
`wherein changing the set of functions changes the trans
`mit and receive characteristics of the network stack;
`and
`
`wherein changing the transmit and receive characteristics
`of the network stack changes the congestion-control
`technique for the network stack.
`20. The computer system of claim 19, wherein the set of
`functions are triggered by events including:
`the receipt of a positive acknowledgement indicating that
`a packet was received;
`the receipt of negative acknowledgements indicating that
`packets may have been lost;
`the receipt of a selective acknowledgement that identi?es
`a received packet;
`
`the expiration of a timer;
`the elapse of a round-trip time interval;
`
`a call-back occurring either before or after a packet
`transmission; and
`the receipt of an explicit congestion noti?cation (ECN).
`
`*
`
`*
`
`*
`
`*
`
`*