Patent Publication Number: US-2011078237-A1

Title: Server, network device, client, and network system

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to a server, a network device, a client device, and a network system. 
     2. Description of the Related Art 
     The real-time streaming technology used to transmit telephone calls and distribute music over the Internet in recent years is now being actively extended to support video distribution services. A number of streaming protocols are in use, including the Real-time Transport Protocol (RTP), the RTP Control Protocol (RTCP), and the RTP Control Protocol Extended Reports (RTCP-XR). In the RTCP and RTCP-XR protocols, for example, a data transmitting party (server) and a data receiving party (client) exchange messages to reporting the quality of service that the server is providing and the client is receiving. The server accordingly sends RTP data packets and RTCP report packets to the client, and the client sends RTCP report packets to the server. This enables telecommunications carriers providing Internet Protocol telephony (IP phone) and other services to confirm that their services are being provided with at least a predetermined quality level. Detailed specifications can be found in Network Working Group Requests for Comments (RFC) 3550 and 3661. 
     A variation of this scheme is disclosed by Miyamoto in Japanese Patent Application Publication No. 2009-94877. In this variation, also based on the RFC 3550 and 3661 protocols, when a network device at an intermediate node in the network transfers RTP data packets from a server to a client, it also measures communication quality parameters from information provided in the packet headers. When the client sends a report packet to the server, the network device may replace the communication parameters in the report with the communication parameters the network device has measured itself. When quality of service deteriorates, the measurements carried out at different network nodes help service providers to identify the node on the network at which the quality of service is being degraded. 
     The report information in RTCP, RTCP-XR, and other such communication protocols pertains only to RTP traffic, that is, to real-time data streams. The techniques disclosed in RFC 3550 and 3661 and by Miyamoto are therefore useful in IP networks directed primarily toward telephony, such as the so-called next generation networks (NGNs), but in IP networks such as the Internet and other internets that incorporate a wide variety of different types of servers providing various types of service to various clients, network performance is not considered in most applications. The information supplied in these reports is useful for evaluating RTP traffic performance in best-effort environments, but has no further value to the IP network. 
     There is a need for a network system that can provide a quality reporting protocol that covers all traffic, so that all applications can obtain information about the quality of service available to them, and all types of service can be improved. 
     SUMMARY OF THE INVENTION 
     An object of the present invention is to enable a client device that receives any type of service from a server through a communication network to obtain information indicating the quality of service that can be provided. 
     Another object is to enable the client device to determine whether a failure to obtain a desired quality of service is due to a problem at the server or a problem in the communication network. 
     A further object is to improve the management and maintenance of the communication network. 
     The invention provides a server connected to a communication network. The server includes a service providing unit that generates payload data, and a network interface unit that generates a packet including the payload data and a capability field. The network interface unit sends the packet to the communication network to be transmitted on a traffic path toward a destination. The payload data may be service data supplied to provide a requested service, or a probe response generated in reply to a probe packet received by the server. The capability field may indicate the capability of the service providing unit to provide the payload data, as determined by a service providing capability measuring unit in the server, or the capability of the traffic path to transfer the packet, as determined by network devices on the traffic path. The packet may include capability fields of both of these types. 
     The invention also provides a network device connected to the server through the communication network. The network device includes a network interface unit that receives the packet sent by the server, a transfer processing unit that determines the next destination of the packet on the traffic path, and a transfer capability measuring unit that determines the packet transfer capability of the network device. The network interface unit sends the received packet to the next destination determined by the transfer processing unit, using the value calculated by the transfer capability measuring unit to update the value in the packet transfer capability field of the packet, or to add a new packet transfer capability field to the packet. A newly added packet transfer capability field may include identifying information identifying the network device that added the new field. 
     The invention also provides a client device connected to the communication network to receive the packet sent by the server. The client device includes an application unit that processes the payload data in the packet, and a quality processing unit that processes the capability field(s) to obtain quality information and provides the quality information to the application unit. When the quality information indicates that a prescribed quality of service cannot be obtained, the application unit takes action such as canceling the service or reducing a requested level of the service. 
     The invention also provides a network system including a server and a network device as described above, a server and a client device as described above, or a server, a network device, and a client device as described above. 
     The capability field or fields in a received packet enable the client device to determine whether a quality problem is due to a problem in the server or a problem in the communication network. If the each network device that transfers the packet adds a new packet transfer capability field including information identifying the network device, the client can isolate network problems to specific network devices and thereby provide information useful in network management and maintenance. 
     Since the capability fields can be attached to all data packets, the information they provide is available to all applications operating on client devices and other devices connected to the communication network. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In the attached drawings: 
         FIG. 1  schematically illustrates a network system used as an example in first to third embodiments of the invention, and the contents of two data packets transferred from servers to a client device in the network system on respective traffic paths; 
         FIG. 2  schematically illustrates the internal structure of either or both of the servers in  FIG. 1  and the contents of a data packet sent by the server; 
         FIG. 3  schematically illustrates the internal structure of a network device in the network system and the contents of a data packet transferred by the network device; 
         FIG. 4  schematically illustrates the internal structure of the client device in  FIG. 1  and the contents of a data packet received by the client device; 
         FIG. 5  is a sequence diagram illustrating the operation of the network system in the first embodiment; 
         FIG. 6  schematically illustrates the internal structure of a server in the second embodiment of the invention; 
         FIG. 7  schematically illustrates the internal structure of a network device in the second embodiment; 
         FIG. 8  schematically illustrates the internal structure of a client device in the second embodiment; 
         FIG. 9  is a sequence diagram illustrating the operation of the network system in the second embodiment; 
         FIG. 10  schematically illustrates the internal structure of a server in the third embodiment of the invention; 
         FIG. 11  illustrates the data structure of a data packet generated by the server in the third embodiment; 
         FIG. 12  schematically illustrates the internal structure of a network device in the third embodiment; 
         FIG. 13  schematically illustrates the internal structure of a client device in the third embodiment; and 
         FIG. 14  illustrates the data structure of a data packet generated by the server in a variation of the third embodiment. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Embodiments of the invention will now be described with reference to the attached drawings, in which like elements are indicated by like reference characters. 
     The packets illustrated in the drawings have headers including source and destination addresses, port numbers, checksums, and other well known information. For simplicity, the headers are not shown in most of the drawings. 
     Each of the servers, network devices, and client devices shown in the drawings includes a central processing unit (CPU) and various peripheral units such as memory and input/output (I/O) units, the latter typically including a display screen and a disk storage unit. A network device includes a queue buffer as part of its memory. These well-known hardware units will be mentioned in the description but, for simplicity, are omitted from the drawings. The units shown in the drawings typically include a combination of parts of the above hardware together with software stored in the memory or the disk storage unit. 
     The term ‘application’ as used herein includes but is not limited to the meaning of ‘application software’. 
     First Embodiment 
     Referring to  FIG. 1 , the network system in the first embodiment includes a server  1   a  connected to an Internet service provider (ISP)  2   a , another server  1   b  connected to another ISP  2   b , and a user device  3   a  connected through a gateway device  3   b  to a third ISP  2   c , which is connected to both of the first two ISPs  2   a ,  2   b.    
     It will be appreciated that  FIG. 1  shows only one exemplary configuration, and that other configurations with different numbers of servers, ISPs, gateway devices, and user devices are also possible. 
     In  FIG. 1 , a data packet  102   a  is transported on a traffic path  201  from server  1   a  through network devices  2   a ,  2   c  and gateway device  3   b  to the user device  3   a . Another data packet  102   b  is transported on another traffic path  202  from server  1   b  through network devices  2   b ,  2   c  and gateway device  3   b  to the user device  3   a . The contents of these data packets  102   a ,  102   b  will be described in more detail later. 
       FIG. 2  shows the generic internal configuration of a server  1  in the first embodiment. The server  1  includes at least a service providing unit  11 , a service providing capability measuring unit  12 , and a network interface unit  13 . The network interface unit  13  is connected to the service providing unit  11  and service providing capability measuring unit  12  and communicates with the network to which the server  1  is connected. At least one of the servers  1   a ,  1   b  in  FIG. 1  has the internal structure shown in  FIG. 2 . The network system may include any number of servers with this internal structure, as well as servers with other internal structures. 
     The service providing unit  11  in  FIG. 2  carries out the usual server function of providing a service, making use of the server&#39;s a CPU, memory, and I/O resources (not shown), and thereby generating service data  1011 , which it sends to the network interface unit  13 . 
     The service providing capability measuring unit  12  measures the instantaneous activity of the server&#39;s CPU, its memory usage, the CPU occupancy rates and memory allocations of application programs running on the server  1 , the rate at which I/O interrupts occur, the current usage of the network interface unit  13 , and other such current or instantaneous values, calculates a service providing capability value  1012 , and sends this value to the network interface unit  13 . 
     In a variation of the first embodiment, instead of measuring current or instantaneous values, the service providing capability measuring unit  12  measures mean values over a period of time, and may also measure the variance or standard deviation of the current or instantaneous values. 
     The network interface unit  13  generates a data packet  101  by appending two fields to the service data  1011  received from the service providing unit  11 : one field for the service providing capability value  1012 ; the other for a packet transfer capability value  1013 . The network interface unit  13  also generates and adds a packet header (not shown). The network interface unit  13  writes the service providing capability value  1012  received from the service providing capability measuring unit  12  in the service providing capability field, writes a prescribed initial value in the packet transfer capability field, calculates the checksum (not shown) from the service data  1011 , service providing capability value  1012 , and packet transfer capability value  1013  and part of the packet header information (not shown), and sends the data packet  101  toward a client device  3 , described below. 
     In the following description, for simplicity, reference numerals  1012  and  1013  will be used both to denote the respective capability values and the fields in which these values are placed. 
     The service data  1011  are the payload data of the data packet  101 , that is, the data to be delivered to the final destination of the packet. 
     Both of the packets  102   a ,  102   b  shown in  FIG. 1  have the same configuration as the data packet  101  in  FIG. 2 . 
       FIG. 3  shows the generic internal configuration of a network device  2  such as a switch or router that relays data in the network system in the first embodiment. The network device  2  includes at least a transfer processing unit  21 , a transfer capability measuring unit  22 , and a network interface unit  23 . The network interface unit  23  is connected to the transfer processing unit  21  and transfer capability measuring unit  22  and communicates with the network to which the network device  2  is connected. 
     When the network interface unit  23  receives a data packet  101 , the transfer processing unit  21  examines the packet header, decides from a table such as a routing table or an address resolution protocol (ARP) table where the data packet  101  should be sent next, and passes the data packet  101  back to the network interface unit  23  to be output from the appropriate port. 
     When the network device  2  relays a data packet, the transfer capability measuring unit  22  measures various current or instantaneous information such as the instantaneous CPU load of the network device  2 , the amount of data currently queued in its queue buffer, the current packet transfer time or its variance, the current load on the network interface unit  23 , the current packet loss rate on the link connected to the network port, the propagation delay to calculate a value indicating a degradation of quality due to the network device  2  itself, and supplies this value to the network interface unit  23  for use in updating the packet transfer capability field  1013 . 
     In a variation of the first embodiment, instead of measuring current or instantaneous values, the transfer capability measuring unit  22  measures mean values over a period of time, and may also measure the variance or standard deviation of the current or instantaneous values. 
     When the network interface unit  23  receives a data packet  101  from the transfer processing unit  21 , it determines whether a packet transfer capability value  1013  has been set in the corresponding field, and if so, updates the packet transfer capability value  1013  by subtracting the quality degradation value supplied by the transfer capability measuring unit  22 . Since this update changes the content of the packet, the network interface unit  23  also recalculates the checksum (not shown) in the packet header. The network interface unit  23  then sends the data packet  101  onward toward the client device  3 . 
     The network system normally includes a plurality of network devices with the internal structure shown in  FIG. 3 . All three of the ISPs  2   a ,  2   b ,  2   c  shown in  FIG. 1  may include network devices with this internal structure, for example. The number of network devices with this structure is not limited. 
     The generic internal structure of the client device  3  referred to above is shown in  FIG. 4 . The user device  3   a  in  FIG. 1  has this internal structure. The gateway device  3   b  in  FIG. 1  may also have this internal structure. The network system may include any number of client devices  3  with this internal structure. 
     As  FIG. 4  shows, the client device  3  includes an application unit  31 , a quality processing unit  32  connected to the application unit  31 , and a network interface unit  33 , connected to the application unit  31  and quality processing unit  32 . The network interface unit  33  communicates with the network to which the client device  3  is connected. 
     The application unit  31  sends service request packets through the network interface unit  33  to a server  1 , and receives the service provided by the server  1 . The application unit  31  also receives quality information from the quality processing unit  32  and takes appropriate action. The appropriate action is taken when a preset quality value is not attained. Various actions may be taken, such as displaying a ‘Service Unavailable’ message on a liquid crystal display (LCD) screen of the client device  3  and canceling data transfer, or displaying a message offering the user of the client device  3   a  a choice of canceling the data transfer or continuing at a reduced service level. The application unit  31  may include the operating system (OS) of the client device  3 . 
     The quality processing unit  32  receives the contents of the service providing capability field  1012  and packet transfer capability field  1013  of each received data packet  101  from the network interface unit  33 , and provides the application unit  31  with quality information including the service providing capability of the server  1  that sent the data packet  101  and the packet transfer capability of the traffic path by which the data packet  101  was received. 
     The network interface unit  33  sends service request packets supplied by the application unit  31  to the appropriate server  1 , verifies data packets  101  received from the server  1  in reply by repeating the checksum calculation and comparing the result with the checksum (not shown) in the packet header, and passes data packets  101  to the application unit  31  if they pass this check. More specifically, the network interface unit  33  passes the service data  1011  of the data packet  101  to the application unit  31 . If a received data packet  101  has a value set in its service providing capability field  1012  and/or packet transfer capability field  1013 , the network interface unit  33  passes those value(s) to the quality processing unit  32 . 
     The operation of the network system in the first embodiment will now be described with reference to  FIG. 5 . The client device  3  in this description is a user device such as the user device  3   a  in  FIG. 1 . 
     In step S 1 , the application unit  31  in the client device  3  sends a service request packet through the client device&#39;s network interface unit  33  to a server  1  to request a desired service from the server  1 . 
     In the next step S 2 , the service providing unit  11  of the server  1  receives the service request packet through the network interface unit  13 . 
     In the next step S 3 , the service providing unit  11  generates service data  1011  to be provided to the client device  3 , and passes the service data  1011  to the network interface unit  13 . 
     In the next step S 4 , the service providing capability measuring unit  12  calculates the server&#39;s service providing capability  1012  as described above, and passes a value representing this capability to the network interface unit  13 . If, for example, only 60% or less of the processing capability of the CPU of the server  1  is currently being utilized and least 20% of its memory space is free, indicating that the server  1  has adequate resources for application operations, and if disk I/O interrupts and other interrupts are not occurring too frequently and usage of the network interface unit  13  is sufficiently light, the network interface unit  13  may assign a value of one hundred (100) to the service providing capability field  1012 , smaller values being assigned as CPU activity, interrupts, and network interface usage increase and free memory space decreases. 
     Although steps S 3  and S 4  are shown as taking place sequentially, they may be carried out concurrently. 
     In the next step S 5 , the network interface unit  13  assembles a data packet  101  by appending the service providing capability value  1012  supplied by the service providing capability measuring unit  12  and an initial packet transfer capability value  1013  (e.g., a value of 100) to the service data  1011  supplied by the service providing unit  11  and calculating a checksum, and sends the data packet  101  onto the network, addressed to the client device  3 . 
     In the next step S 6 , the data packet  101  is received by the network interface unit  23  of a network device  2 , and passed to the transfer processing unit  21  of the network device  2 . 
     In the next step S 7 , the transfer processing unit  21  determines the destination of the data packet  101  on the next hop of its traffic path toward the client device  3  and the port from which the data packet should be transmitted to this next destination, and passes the data packet back to the network interface unit  23 . 
     In the next step S 8 , the transfer capability measuring unit  22  calculates the network device&#39;s packet transfer capability value  1013  as described above, and passes this value to the network interface unit  23 . If, for example, only 60% or less of the processing capability of the CPU of the network device  2  is currently being utilized and its queue buffer is less than 5% full, and the network interface unit  23  is less than 20% loaded, the network interface unit  23  may set a value of zero (0) in the packet transfer capability field  1013 , larger values being set as CPU utilization, queue buffer utilization, and network interface utilization increase. 
     Although steps S 7  and S 8  are shown as taking place sequentially, they may be carried out concurrently. 
     In the next step S 9 , the network interface unit  23  updates the packet transfer capability field  1013  of the data packet  101  by subtracting the value supplied by the transfer capability measuring unit  22 , recalculates the checksum, and sends the packet on the next hop of its traffic path toward the client device  3 . Steps S 6  to S 9  are repeated at each network device on this traffic path, the value in the packet transfer capability field  1013  gradually diminishing as the data packet  101  traverses the traffic path. 
     In the next step S 10 , the network interface unit  33  of the client device  3  receives the data packet  101  from the last network device  2  on the traffic path and verifies its checksum as described above. If the checksum is correct, the network interface unit  33  passes the service providing capability value  1012  and packet transfer capability value  1013  (if present) to the quality processing unit  32 , and passes the service data  1011  to the application unit  31 . The application unit  31  processes the service data  1011  in the normal manner, unless there is an interrupt from the quality processing unit  32 . 
     In the next step S 11 , the quality processing unit  32  generates quality information from the service providing capability value  1012  and packet transfer capability value  1013 , and generates an interrupt if the service providing capability value  1012  or packet transfer capability value  1013 , or a value calculated therefrom, fails to attain a predetermined value. This interrupt triggers the next step S 12 . 
     In step S 12 , the application unit  31  receives the quality information from the quality processing unit  32  and takes appropriate action as described above. 
     When the server  1  is unable to obtain requested service from the server  1 , the quality information provided by the quality processing unit  32  enables the application unit  31  to determine whether the fault lies with the server  1  itself or with the network. When the fault lies with the network, client devices  3  that have issued non-urgent service requests and find themselves receiving inferior service can cancel their service requests, thereby relieving traffic congestion on the network and enabling other clients to obtain an adequate level of service. 
     This effect is achieved simply by appending fields for the service providing capability value  1012  and packet transfer capability value  1013  to data packets generated by the server  1 , without requiring the generation and transmission of separate quality measurement report packets. 
     In a variation of the first embodiment, the packet transfer capability field  1013  is added by a network device  2  instead of by the server  1 . When the network device  2  receives a data packet lacking a packet transfer capability field  1013 , the network interface unit  23  calculates a packet transfer capability value  1013  by, for example, subtracting the value supplied by the transfer capability measuring unit  22  from a predefined initial value, appends the calculated packet transfer capability value  1013  to the data packet, and sends the data packet with the appended packet transfer capability value  1013  to the next network device or the client device  3 . 
     In another variation of the first embodiment, the server  1  adds a service providing capability field  1012  and a packet transfer capability field  1013  to, for example, every Nth data packet, where N is an integer greater than one, instead of adding these fields  1012 ,  1013  to every data packet. 
     In another variation of the first embodiment, the server  1  adds only a service providing capability field  1012  or only a packet transfer capability field  1013 , instead of both a service providing capability field  1012  and a packet transfer capability field  1013 , to the data packets, and the application unit  31  in the client device  3  takes action based only on the service providing capability value  1012  or only on the packet transfer capability value  1013 . 
     In another variation of the first embodiment, the service providing capability value  1012  and packet transfer capability value  1013  are received and processed by, for example, the gateway device  3   b  in  FIG. 1  instead of the user device  3   a , and the gateway device  3   b  takes appropriate action when the necessary quality of service is not obtained. 
     Second Embodiment 
     Whereas the first embodiment only enables the server or the network as a whole to be identified as being responsible for a quality of service problem, the second embodiment enables responsibility to be traced to individual network devices. 
     Referring to  FIG. 6 , the server  1  in the second embodiment includes a service providing unit  11   a , a service providing capability measuring unit  12 , and a network interface unit  13   a  generally similar to the corresponding elements in the first embodiment and similarly interconnected. 
     The service providing capability measuring unit  12  operates as described in the first embodiment. The service providing unit  11   a  operates as described in the first embodiment in generating data packets, and also generates probe responses  1014  in reply to probe packets received from a client device  3 . 
     The network interface unit  13   a  operates as described in the first embodiment in receiving service request packets and sending data packets, and also receives probe packets, passes each received probe packet to the service providing unit  11   a , receives a probe response  1014  from the service providing unit  11   a , appends the service providing capability value  1012  supplied by the service providing capability measuring unit  12  to the probe response  1014  and adds a packet header (not shown) to generate a data packet  101   a , and sends the data packet  101   a  on a traffic path leading to the client device  3 . The probe response  1014  is the payload data of the data packet  101   a.    
     Referring to  FIG. 7 , the network device  2  in the second embodiment includes a transfer processing unit  21   a , a transfer capability measuring unit  22   a , and a network interface  23   a , generally similar to the corresponding elements in the first embodiment and similarly interconnected. 
     The transfer processing unit  21   a  processes both data packets  101  including service data and the data packets  101   a  including probe responses  1014  in the same way, by selecting the next destination of the packet on its traffic path and supplying the necessary address and port information to the network interface  23   a , as described in the first embodiment. 
     The transfer capability measuring unit  22   a  operates in the same way as the transfer capability measuring unit  22  in the first embodiment, except that it calculates packet transfer capability values when both types of data packets  101 ,  101   a  are received. 
     The network interface  23   a  operates in the same way as the transfer capability measuring unit  22  in the first embodiment, except that when sending a data packet including a probe response  1014 , instead of updating the packet transfer capability value, it generates a first packet transfer capability field  1013   a  by adding identifying information such as the Internet Protocol (IP) address of the network device  2  to the value supplied by the transfer capability measuring unit  22   a , appends the first packet transfer capability field  1013   a  to the data packet  101   a , recalculates the checksum (not shown), and sends the resulting data packet  101   b , including the probe response  1014 , service providing capability value  1012 , and first packet transfer capability value  1013   a , toward the client device  3 . 
     Referring to  FIG. 8 , the client device  3  in the second embodiment includes an application unit  31   a , a quality processing unit  32   a , and a network interface unit  33   a , generally similar to the corresponding elements in the first embodiment and similarly interconnected. 
     The application unit  31   a  performs the operations described in the first embodiment. In addition, when notified of inadequate service quality by the quality processing unit  32   a  or by the user of the client device  3 , or when the application unit  31   a  itself detects inadequate service quality, the application unit  31   a  generates a probe packet, and sends the probe packet through the network interface unit  33   a  to the server  1  that provided the inadequate service. Furthermore, the appropriate action taken by the application unit  31   a  in response to quality information received from the  32   a  may include action directed toward a specific network device, such as sending a report to the relevant internet service provider. 
     The quality processing unit  32   a  operates as described in the first embodiment in generating quality information from the service providing capability value  1012  and packet transfer capability value  1013  included in an ordinary data packet  101 . In addition, when provided with a data packet  101   b  including a probe response  1014 , the quality processing unit  32   a  generates more detailed quality information including, for example, the identifiers of specific network devices that are causing packet transfer problems, and sends this more detailed quality information to the application unit  31   a.    
     The network interface unit  33   a  operates as described in the first embodiment, except that when it receives a data packet  101   b  including a probe response  1014 , it passes the entire data packet  101   b  to the quality processing unit  32   a  and, if necessary, to the application unit  31   a.    
     The operation of the network system in the second embodiment will now be described with reference to  FIG. 9 . 
     In step S 21 , the application unit  31   a  in the client device  3  sends a service request packet through the network interface unit  33   a  to the server  1  to request a desired service from the server  1 . 
     In the next step S 22 , the server  1  replies to the service request packet by sending a data packet  101  to the client device  3  as described in the first embodiment. 
     In the next step S 23 , a deficiency in the quality of service is detected at the client device  3 , either by the quality processing unit  32   a  as described in the first embodiment, or by the application unit  31   a  or the user of the client device  3 , and the application unit  31   a  sends the server  1  a probe packet through the network interface unit  33   a  to investigate the cause of the problem. 
     In the next step S 24 , the application unit  31   a  at the server  1  receives the probe packet through the network interface unit  33   a.    
     In the next step S 25 , the application unit  31   a  generates a corresponding probe response  1014  and supplies it to the network interface unit  13   a.    
     In the next step S 26 , the service providing capability measuring unit  12  calculates the server&#39;s service providing capability  1012  as described in the first embodiment, and passes this value to the network interface unit  13   a . Steps S 25  and S 26  may be carried out concurrently. 
     In the next step S 27 , the network interface unit  13  assembles a data packet  101   a  by appending the service providing capability value  1012  supplied by the service providing capability measuring unit  12  to the probe response  1014  supplied by the service providing unit  11 , and sends the data packet  101   a  onto the network, addressed to the client device  3 . 
     In the next step S 28 , the data packet  101   a  is received by the network interface  23   a  of a network device  2 , and passed to the transfer processing unit  21   a  of the network device  2 . 
     In the next step S 29 , the transfer processing unit  21   a  determines the destination of the data packet  101   a  on its next hop toward the client device  3  and the port from which it should be transmitted on this next hop, and passes the data packet  101   a  back to the network interface  23   a.    
     In the next step S 30 , the transfer capability measuring unit  22   a  calculates the network device&#39;s packet transfer capability as described in the first embodiment and passes this value to the network interface  23   a . Steps S 29  and S 30  may be carried out concurrently. 
     In the next step S 31 , the network interface  23   a  generates a first packet transfer capability field  1013   a  by adding identifying information to the value supplied by the transfer capability measuring unit  22   a , appends the first packet transfer capability field  1013   a  to the data packet  101   a , and sends the resulting data packet  101   b  on its next hop toward the client device  3 . 
     Steps S 28  to S 31  are repeated at each network device  2  on the traffic path to the user device  3 . At the next network device  2 , the data packet  101   b  acquires a second packet transfer capability field  1013   b , which is appended behind the first packet transfer capability field  1013   a  as shown in  FIG. 7 . At further hops, the data packet  101   b  acquires further packet transfer capability fields, each including the identifier of the network device  2  by which it was added. 
     In the next step S 32 , the network interface unit  33  of the client device  3  receives the data packet  101   b  from the last network device  2  on the traffic path, and passes the data packet  101   b  to the quality processing unit  32   a . The data packet  101   b  may also be passed to the application unit  31   a  if necessary. 
     In the next step S 33 , the quality processing unit  32   a  analyzes the service providing capability field  1012  and packet transfer capability fields  1013   a ,  1013   b , . . . included in the data packet  101   b  according to threshold values or the like to derive quality information indicating the source of the service quality problem, and passes this quality information to the application unit  31   a . For example, if the service providing capability value  1012  is below a first threshold, the quality information indicates that the service providing capability of the server  1  is inadequate; if the first packet transfer capability value  1013   a , the second packet transfer capability value  1013   b , or another packet transfer capability value is below a second threshold value, the quality information indicates that the packet transfer capability of the network device  2  identified by the identifying information attached to the particular packet transfer capability value is inadequate. If any inadequacy is found, the quality processing unit  32   a  generates an interrupt to notify the application unit  31   a , triggering the next step S 34 . 
     In the step S 34 , the application unit  31   a  receives the quality information from the quality processing unit  32   a  and takes appropriate action as described above. 
     By attaching a string of packet transfer capability fields to data packets  101   b  sent in response to probe packets, the second embodiment provides more detailed information than the first embodiment as to the specific locations of network problems. Because this more detailed information is available, there is less need for the information provided by the service providing capability and packet transfer capability values added to service data packets  101 , so this information may be added less frequently than in the first embodiment, thereby using network bandwidth resources more efficiently. 
     By allowing the client device  3  to provide information about specific network devices  2  to internet service providers or other network administrators, the second embodiment can contribute to the improvement of overall network management. This information can be used, for example, to identify overloaded or malfunctioning network devices, so that they can be replaced or repaired. 
     In a variation of the second embodiment, instead of sending probe packets when specific service quality problems are recognized, the client device  3  sends probe packets at regular intervals, or when general network quality problems are recognized. 
     In another variation of the second embodiment, data packets including probe responses are processed in the same way as service data packets, by updating the packet transfer capability field at each network device  2  by subtracting a value supplied by the transfer capability measuring unit  22   a , instead of appending a new packet transfer capability field at each network device. 
     Conversely, service data may be processed in the same way as data packets including probe responses, by appending a new packet transfer capability field at each network device  2 , instead of by updating the packet transfer capability field at each network device  2  by subtracting a value supplied by the transfer capability measuring unit  22   a.    
     In another variation of the second embodiment, only a service providing capability or only a packet transfer capability field, instead of both a service providing capability and a packet transfer capability field, are added to data packets including probe responses, and the application unit  31  in the client device  3  takes action based only on the service providing capability value  1012  or only on the packet transfer capability value  1013 . 
     Third Embodiment 
     The third embodiment restricts the range of coverage of the checksum in the first or second embodiment. 
     Referring to  FIG. 10 , the server  1  in the third embodiment includes at least a service providing unit  11 , a service providing capability measuring unit  12 , and a network interface unit  13   b  that are generally similar to the corresponding elements in the first embodiment and are similarly interconnected. 
     The service providing unit  11  and service providing capability measuring unit  12  operate as described in the first embodiment. The network interface unit  13   b  operates as described in the first embodiment in generating a data packet by adding a service providing capability field  1012  and a packet transfer capability field  1013  to service data  1011  provided by the service providing unit  11 , but adds a packet header, differing from the packet header added in the first embodiment, to the resulting data packet  101   c . Referring to  FIG. 11 , the packet header  1015  in the third embodiment includes address and port information and a checksum value as mentioned in the first embodiment, but also includes a checksum coverage range field indicating that the checksum value has been calculated only from the information in the packet header  1015 , the service data  1011 , and the service providing capability value  1012 . The checksum accordingly does not guarantee the validity of the packet transfer capability value  1013 . The network interface unit  13   b  calculates the checksum as if the packet transfer capability field  1013  were absent. 
     Referring to  FIG. 12 , the network device  2  in the third embodiment includes at least a transfer processing unit  21 , a transfer capability measuring unit  22 , and a network interface  23   b  that are generally similar to the corresponding elements in the first embodiment and are similarly interconnected. 
     The transfer processing unit  21  and transfer capability measuring unit  22  operate as described in the first embodiment. The network interface  23   b  also operates as described in the first embodiment, except that it does not recalculate the checksum in the packet header  1015  after updating the packet transfer capability value  1013 . 
     Referring to  FIG. 13 , the client device  3  in the third embodiment includes at least an application unit  31 , a quality processing unit  32 , and a network interface unit  33   b  that are generally similar to the corresponding elements in the first embodiment and are similarly interconnected. 
     The server  1  and quality processing unit  32  operate as described in the first embodiment. The network interface unit  33   b  also operates as described in the first embodiment, except that in verifying the checksum value in a received service data packet, it excludes the packet transfer capability field  1013  (if present) from the checksum calculation. 
     The third embodiment operates in the same way as the first embodiment, except for differences in steps S 5 , S 9 , and S 10  in  FIG. 5 . 
     In step S 5 , when assembling a data packet  101   c  by appending the service providing capability field  1012  and packet transfer capability field  1013  to the service data  1011 , the network interface unit  13   b  calculates the checksum on the basis of the packet header  1015 , service data  1011 , and service providing capability value  1012 , excluding the packet transfer capability value  1013 . 
     In step S 9 , after updating the packet transfer capability value  1013 , the network interface  23   b  does not recalculate the checksum but sends the packet on the next hop of its traffic path with the checksum unaltered. 
     In step S 10 , in verifying the checksum of a received data packet  101 , the network interface unit  33   b  excludes the packet transfer capability value  1013  from the checksum calculation. 
     By excluding the packet transfer capability value  1013  from the checksum calculation, the client device  3  eliminates the need to recalculate and update the checksum at every network device  2  on the traffic path, and shortens the checksum calculation at the server  1  and client device  3  at both ends of the traffic path, thereby reducing the data processing load on all devices involved, and in particular on the network devices  2 . This load reduction entails the possibility that the received packet transfer capability value  1013  may be incorrect, but does not compromise the reliability of the other data in the received packet  101   c.    
     Referring to  FIG. 14 , in a variation of the third embodiment, data packets  101   d  including probe responses  1014  sent in reply to a probe packet as in the second embodiment also have a packet header  1015  with a checksum coverage range field, and this checksum coverage range field indicates that the packet transfer capability values  1013   a ,  1013   b , . . . added to the packet  101   d  as it traverses its traffic path are excluded from the checksum. The checksum is accordingly calculated only from the packet header  1015 , the probe response  1014 , and the service providing capability value  1012 . The effect of reduced processing load is therefore also obtained for probe response packets. 
     In a further variation of this variation, the packet transfer capability value  1013  of a data packet including a probe response is updated as in the first embodiment. The updated packet transfer capability value  1013  is also excluded from the checksum calculation in this variation. 
     Conversely, packet transfer capability fields  1013  including identifying information may be appended to service data packets, instead of simply updating a single packet transfer capability value  1013 . All of the appended packet transfer capability fields  1013  are excluded from the checksum calculation. 
     In all of these variations, no checksum calculations are performed at network devices  2  on the traffic path of a packet. 
     Those skilled in the art will recognize that further variations are possible within the scope of the invention, which is defined in the appended claims.