100 likes | 105 Views
This document addresses issues with the DESCRIPTION in RFC 4022 and 4113, provides suggestions to clarify behavior, and proposes potential solutions.
E N D
Anders Persson Sun Microsystems anders.persson@sun.com Issues regarding RFC 4113 and 4022July 12, 2006 Alain Durand Paul Schauer Comcast {Alain_Durand, Paul_Schauer}@cable.comcast.com
Overview • Issues • RFC 4022 and 4113 have several objects with DESCRIPTION that are insufficient • The behavior can be interpreted in several ways • Varying behavior across different entities • Outline • Describe why the current behavior is unclear • Provide a couple of suggestions that would at least clarify the behavior
Issue #1: Process Objects • Each TCP connection/UDP endpoint is associated with a single system process • Behavior not clear when: • There are multiple processes • Example: A process use fork() to create a child process • There is a process, but it cannot be determined • Need to either clarify the DESCRIPTION or take a new approach
Possibility 1: Update DESCRIPTION • Need to amend the DESCRIPTION to clarify how to behave when: • A process is associated with the connection, but it cannot be determined • Currently a zero value is used to identify situations where no process is available • Extend the definition of the zero value to include cases where the process cannot be determined • There are multiple processes associated with one connection • Pick any of the processes to report • Set to zero if it is not possible to report any of them
Possibility 2: New Table • The current method of associating connections and processes is limited • Deprecate the Process objects and provide better functionality through a new table • Table could provide a one-to-many association between processes and connections • Example: Process Row Pointer 45 tcpConnection.ipv4.”127.0.0.1”.1234.ipv4.”127.0.0.1”.5678 45 tcpConnection.ipv4.”127.0.0.1”.4321.ipv4.”127.0.0.1”.8765
Issue #2: udpEndpointInstance • Background • Possible to have multiple UDP endpoints with the same tuple • Example: An application using SO_REUSEADDR when binding UDP to a particular port • Instance is used to distinguish between otherwise identical UDP endpoints • Issues • How often can the Instance be reused? • Are Instance values assigned in any particular order?
Examples • Scenario 1: • Initially we have a connection with tuple A and instance x (A.x) • A.x is then terminated, and an identical connection open, which is assigned instance y (A.y) • If x and y are identical, then it will not be possible to identify that a change has occurred • Scenario 2: • In the scenario above, A.x does not terminate, but A.y still opens • What is the relationship between x and y? Should x < y since A.x is older than A.y?
Possibility 1: Update DESCRIPTION • Amend the DESCRIPTION to clarify: • Reuse Policy • Need to explicitly state that infrequent reuse is expected • Allocation Policy • Arbitrary assignment so that the person implementing has maximum flexibility • Motivation: Reduce reuse frequency • Benefit • Minimal change; does not require any new objects
Possibility 2: Add INDEX Object • Possible solution • Add a Time stamp based object to udpEndpoint and include it in the INDEX • Use the Instance only to differentiate between identical endpoints that are created in the same time interval • Benefits • Provides managers with a guaranteed reuse frequency • Information about when the connection was created
Alain Durand Paul Schauer Comcast {Alain_Durand, Paul_Schauer}@cable.comcast.com Anders Persson Sun Microsystems anders.persson@sun.com