FR2908577A1 - Quality of service resource managing method for e.g. domestic network, involves sending information representing accepted value to receiver device to initialize transmission of content based on window size equal to accepted value - Google Patents

Abstract

The method involves determining a group of values of acceptable window size for the transmission of multimedia content. A value of window size is determined, where the value is accepted from the group of values of acceptable window size, and the accepted value is maximum value of window accepted by an intermediate quality of service device (140) for the transmission of content. Information representative of the accepted value is sent to a receiver device for initializing the transmission of content between source and receiver devices based on the size of window equal to the accepted value. Independent claims are also included for the following: (1) a computer program product downloadable from a communication network and/or recorded on a readable support, comprising program code instructions for implementing a method for managing resources (2) a storage unit storing a set of instructions by a computer for implementing a method for managing resources (3) a managing device comprising a resources managing unit for the transmission of data content in a communication network (4) a transmission device comprising a resource managing unit for transmission of data content in a communication network.

Description

1 Transmission method in accordance with a transmission protocol by

  bursts of data content, computer program product, storage medium and corresponding device. FIELD OF THE INVENTION The field of the invention is that of transmissions of data contents in a communication network. More specifically, the invention relates to the control of the quality of service implemented in the context of such transmissions. 2. Solutions of the Prior Art Automated Repeat ReQuest (ARQ) protocols are error control protocols in the transmission of data in which the receiver detects transmission errors of a message or a message. dataset and automatically requests the retransmission of this message or dataset to the sender.

  IP networks (for Internet Protocol that is defined by the IETF RFC791) can support both UDP-compliant and TCP-compliant traffic.  The UDP protocol (for User Datagram Protocol which is defined by the RFC768 standard of the IETF) is intended for real-time transactions (without forwarding principle) allowing fast transmissions but without insurance of the delivery of packets.  This is the principle of the unconnected mode or datagram: there is no way to check if all the packets sent have arrived at the destination, nor to check in which order the packets arrived.  As explained in Annex 1, which presents the principles of TCP operation, the Transmission Control Protocol (TCP) defined by the IETF RFC793 is an ARQ protocol or transmission protocol. bursts that is based on control mechanisms and retransmission, and ensures the delivery of each packet to the destination.  However, this protocol is not efficient for real-time type exchanges.  For this type of exchange (in real time), 2908577 2 it is often better to manage losses, errors or congestion, rather than trying to avoid them.  The purpose of the "Universal Plug and Play" standard (hereinafter referred to as the UPnP standard) is to enable simple and efficient systems and equipment to be networked and collaborated without prior configuration.  UPnP compatible devices include audio-video devices or personal computers (PCs) manufactured by various companies.  These devices can be integrated into a local IP 10 (for Internet Protocol) network such as a home network.  The UPnP standard provides a compatible device with means of dynamic connection to a UPnP network (which implements the UPnP standard), allows it to discover other compatible devices of the network and allows it to communicate (or expose) its own capabilities.  UPnP technology is based on the TCP / IP network protocol, the HTTP protocol (for HyperText Transport Protocol) and the XML protocol (for Extensible Markup Language).  The essential components of a UPnP network are the equipment, the services offered by this equipment and the control points (or control 20 points in English).  UPnP equipment (which implements the UPnP standard) can support several services, and is categorized according to the list of services (for example a service of video content server type, a printer type service, etc.). ) that he can provide.  A UPnP equipment exposes the services it can implement (we will talk about the rest of its services) by means of an XML description file.  A service in UPnP equipment includes a state machine, a control server, and an event server.  The state machine models a state of service by updating state variables characterizing the equipment.  The control server receives the requests from remote equipments, executes the associated commands and updates the state machine.  The event server orchestrates the broadcast on the network of this update with the UPnP equipment having shown their interest in this information.  A UPnP control station is able to discover and control UPnP devices from the UPnP network.  When new equipment is discovered by the control station, the latter obtains a description of this new equipment, is therefore aware of the services offered by this equipment, asks for a precise description of each available service and finally sends service control requests. selected.  The control station may also subscribe to the event server to be notified of any state changes.  The UPnP Audio Visual standard (for UPnP visual audio, hereinafter referred to as UPnP AV) defines a set of UPnP devices (eg TVs, VCRs, DVD players, MP3 players, PCs, etc.). . . ) with their associated services, which are more specifically dedicated to the digital audio / video world.  The three main logical entities of a UPnP AV network (which implements the UPnP AV standard) are: a media server (or UPnP MediaServer) having access to multimedia contents that it can broadcast on the local network, a reader media (or UPnP MediaRenderer) capable of playing locally this type of multimedia content received from the network, and a control station coordinating the operations requested by the user (such as play, stop, pause,. . . ).  The media server and the media player do not implement the UPnP protocol to exchange information directly with each other.  Indeed, in order to exchange multimedia contents, they use protocols apart from the UPnP protocol (they are called out-of-band protocols).  These outof-band protocols are mainly HTTP (for HyperText Transfer Protocol as defined in RFC2616) over TCP / IP, and RTP (for Real-time Transport Protocol as defined in RFC). 1889) above the UDP protocol.  2908577 4 The UPnP Quality of Service standard (for UPnP Quality of Service, hereinafter referred to as UPnP QoS), as described in the UPnP QoS standard vl reference document. 0 / v2. 0, defines a set of UPnP services related to quality of service management, which are integrated with UPnP devices.  Three services are defined as follows: the UPnP QosPolicyHolder service, hereinafter referred to as QosPolicyHolder, which manages Quality of Service (hereinafter QoS) policies validated by a user and to be applied on the network; The UPnP service QosDevice, hereinafter referred to as QosDevice, which is a service of a network equipment for receiving the QoS instructions to be applied to a data stream of a particular content; and the UPnP QosManager service, hereinafter referred to as QosManager, which, on the order of a Control Station wishing to set up a multimedia flow, is in charge of collecting the QosPolicyHolder policy and informing the QosDevice. on the transmission path of the flow of actions to set up.  Quality of Service (QoS) guarantee requests come from 20 distributed multimedia applications that are no longer satisfied with the best possible service of the Ethernet protocol.  These applications range from simple data transfer to more complex ones such as telephony, video on demand or multimedia conferencing.  The characterization, in terms of QoS requirements, of a UDP-compliant flow is accomplished by means of a descriptive model of multimedia traffic otherwise known in English as Traffic Specification or TSPEC (hereinafter referred to as TSPEC).  The TSPEC structure contains a list of parameters defining the transfer characteristics of the stream (for example the most important are the necessary bandwidth, latency, jitter).  This structure is particularly used by centralized signaling protocols such as the UPnP QoS protocol and online signaling protocols such as the RSVP protocol.  However, the TSPEC structure is not suitable for characterizing, in terms of QoS requirements, flows in accordance with the TCP burst transmission protocol (commonly referred to as elastic streams) because the reliable transport mechanisms of the TCP protocol (use of a slippery window, the slow start slow start algorithm, the congestion avoidance congestion avoidance algorithm, the fast retransmit fast retransmit algorithms and fast recovery fast recovery, etc. ) make the network behavior of this TCP protocol unpredictable throughout a communication.  A stream transmitted in accordance with the TCP protocol behaves in such a way that it tries to share the bandwidth as best as possible with the different competing flows.  However, when the memory space in the network interconnection equipment becomes insufficient (which results for example in congestion situations), timeout expirations appear, which results in a retransmission. TCP-compliant lost packets.  These retransmissions amplify the situations of congestion.  Indeed, since the transmitting device does not receive acknowledgment from the receiving device for the transmitted data (due to congestion), it retransmits the unacknowledged data.  As previously explained, the need for a guarantee (or quality) of service for the transmission of multimedia streams (in terms of bandwidth, and / or real-time criticality) is increasing with the increase in the number of multimedia equipment deployed. by the users.  However, in order to ensure this QoS, a management of the TCP protocol behavior is necessary in order to avoid congestion on the interconnection equipment of the network and to respect the requests for QoS of the streams transmitted in accordance with FIG. TCP protocol (congestion, 2908577 6 timeout) but also to prevent disturbances (such as delays or jitter) affecting UDP compliant flows.  Techniques for managing the behavior of the TCP protocol have been proposed in the prior art.  Such techniques include, for example, controlling the admission of streams or dynamically adjusting the windowing of the TCP protocol.  They are based on a measurement of network performance at a given moment (for example, on the calculation of RTT or Round Trip Time).  However, these conventional techniques are localized on interconnection equipment on the network, and do not take into account an overview of the characteristics of the network.  3.  OBJECTS OF THE INVENTION The invention, in at least one embodiment, has the particular objective of overcoming these disadvantages of the prior art.  More specifically, an object of the invention, in at least one of its embodiments, is to provide a technique for managing the reservation of resources, in a network implementing a centralized signaling protocol, during transmission. content in accordance with a burst transmission protocol that can reduce congestion phenomena.  Another object of the invention, in at least one of its embodiments, is to implement such a technique which applies to the entire network.  Another objective of the invention, in at least one of its embodiments, is to implement such a technique that is compatible with the recommendations of the protocols implemented.  The invention, in at least one of its embodiments, still aims to implement such a technique that is simple to implement and for a low cost.  4.  DISCLOSURE OF THE INVENTION In a particular embodiment of the invention, there is provided a resource management method for transmitting in a communication network a first data content between a first source device and a device. first receiver device on a first transmission path comprising at least a first intermediate device.  According to the invention, a manager device performs the following steps: determining a set of acceptable window size values for transmitting the first content; determining a window size value, said first accepted value, from the set of acceptable acceptable window size values, said first accepted value being the maximum window value accepted by at least said at least one first intermediate device for the transmission of the first content; sending, to the first receiving device, information representative of said first accepted value in order to initialize the transmission of the first content between the first source device and the first receiver device 15 according to a window size equal to said first accepted value.  The general principle of the invention consists, in a network (for example implementing a centralized signaling protocol), of dynamically adjusting (or adapting) the window size values of the contents to be transmitted in accordance with the burst transmission protocol.  Thus, resource reservation management is achieved when transmitting content in accordance with a burst transmission protocol which makes it possible to reduce congestion phenomena in the network.  In the context of the invention, this adjustment can be implemented by the management device of the centralized signaling protocol.  Thus, this management is centralized and takes into account the entire network.  Thus, it is possible to obtain a complete quality of service (QoS) controlled by at least one equipment compliant with the centralized signaling protocol on a local network for content transmitted according to a burst transmission protocol.  Furthermore, the method according to the invention makes it possible to implement QoS resource reservation in a communication network in a completely transparent manner for the user.  Preferably, the step of determining the first accepted value 5 also comprises the following steps: selecting an acceptable window size value from the set of acceptable window size values, said first current selected value; determining if the first current selected value is accepted by said at least one first intermediate device; in the case of a negative determination, reiterating the selection and determination steps with a first selected value below the first selected current value.  Thus, the first accepted value is obtained by testing, at least with the at least one intermediate device, different acceptable window size values.  Advantageously, the step of determining whether the first current selected value is accepted by said at least one first intermediate device comprises the following step: sending to said at least one first intermediate device a request for resource allocation corresponding to the first selected current value, and a window size value is considered to be accepted by said at least one first intermediate device when the manager device receives from said at least one first intermediate device a positive resource allocation report corresponding to the first current selected value.  According to one characteristic of the invention, prior to the reiteration step, it comprises the following steps: determination of one or more devices, said device (s) accepting, among the first device (s) ) intermediate (s), having accepted the first selected current value; sending to said accepting device (s) a resource release request corresponding to the first current selected value.  Thus, resources can be released at those devices that have accepted the first current selected value, which allows these devices to be able to transmit other streams (or contents).  According to one embodiment of the invention, in the case where no first selected value is accepted in the step of determining a first accepted value, the management method also comprises the following steps: minus a second data content, the second content being transmitted between a second source device and a second receiver device on a second transmission path comprising at least a second intermediate device, at least one of the second or said second device (s) intermediate device (s) being also one or more of said first intermediate device (s); determining an acceptable window size value, said second acceptable value, for transmitting the second content; sending, to at least said at least one second intermediate device, information representative of said second acceptable value to update the transmission of the second content by a window size equal to said second acceptable value.  Thus, it is possible to reallocate, at the level of a device of the first transmission path, part of the resources dedicated to the transmission of the second content to the transmission of the first content.  Preferably, a window size value is said to be acceptable for the transmission of a content if it satisfies at least one of the criteria belonging to the group comprising: the window size value is greater than a maximum packet size value of content; - the window size value is greater than a predefined minimum value checking n * MSS, where n is a content-dependent coefficient and MSS is a maximum packet size value of the content 5 - the size value window is greater than a minimum window size for transmission of lower priority content; the window size value is less than a max_bandwidth * RTT product on the content transmission path, where max_bandwidth is the maximum theoretical bandwidth on the content transmission path and RTT is an averaged value of the travel time of the content transmission path. path of transmission of the content.  The invention also relates to a method for managing resources for the transmission in a communication network of a data content between a source device and a receiving device on a transmission path comprising at least one intermediate device.  According to the invention, one of said intermediate devices, said device involved, performs the following steps: receiving a message comprising a window size value accepted by at least said at least one intermediate device for the transmission of said content; determining the position, on the transmission path, of said device involved; - In the case where the device involved is the receiving device, sending to the source device of a message, said first initialization message, initialization of the transmission of the content, said first initialization message comprising the accepted value.  According to one embodiment of the invention, in the case where the device involved is not the receiver device, the method comprises the following steps: reception of a message, said second initialization message, initialization message Transmission of the content, said second initialization message comprising at least one value indicating a level of resources available on the receiving device for transmitting the content, said retained value; 5 - determining whether the value selected is greater than the accepted value; if the value selected is greater than the accepted value, modifying said second initialization message, replacing the value retained by the accepted value; sending said second initialization message to the source device.  Preferentially, in the case where the device involved is not the receiving device, the method comprises the following steps: reception of a message, said acknowledgment message, acknowledgment of the initialization of the transmission of the content said acknowledgment message comprising at least one value indicative of a level of resources available on the server for transmitting the content, said retained value; - determination whether the value selected is greater than the accepted value; if the value selected is greater than the accepted value, modification of said acknowledgment message, replacing the value retained by the accepted value; sending said acknowledgment message to the receiver device.  Advantageously, if the value selected is not greater than the accepted value, the management method further comprises the following step: sending to a management device conforming to a centralized signaling protocol a message comprising the value retained, to allow updating of an accepted window size value for the data content.  According to one characteristic of the invention, the management method further comprises the following steps: receiving at least one packet of the content; Determining from said at least one received packet of a minimum value of window size for the transmission of the content, said lower value; sending to a manager device, the lower value, in order to allow an update of a set of acceptable window size values for the transmission of the content.  According to one characteristic of the invention, the lower value corresponds to a maximum packet size value of the content.  Advantageously, a window size value is said to be acceptable for the transmission of a content if it satisfies at least one of the criteria belonging to the group comprising: the window size value is greater than a maximum packet size value of content; the window size value is greater than a predefined minimum value satisfying n * MSS, where n is a coefficient dependent on the priority of the content and MSS is a maximum value of the packet size of the content - the window size value is greater than a minimum window size for transmission of lower priority content; The window size value is less than a product max_bandwidth * RTT on the content transmission path, where max_bandwidth is the maximum theoretical bandwidth on the content transmission path and RTT is an averaged value of the travel time of the content. path of transmission of the content.  The invention also relates to a computer program product, downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, comprising program code instructions for the implementation of resource management methods as previously described.  The invention also relates to a storage medium, possibly totally or partially removable, readable by a computer, storing a set of instructions executable by said computer to implement the resource management methods as previously described.  The invention also relates to a management device comprising resource management means for the transmission in a communication network of a first data content between a first source device and a first receiver device on a first transmission path comprising at least a first intermediate device.  According to the invention, the management means comprise: means for determining a set of acceptable window size values for the transmission of the first content; means for determining a window size value, said first accepted value, from the set of acceptable acceptable window size values, said first accepted value being the maximum window value accepted by at least said at least one first intermediate device for transmission of the first content; to the first receiving device, information representative of said first accepted value to initialize the transmission of the first content between the first source device and the first receiver device according to a window size equal to said first accepted value.  According to a feature of the invention, the means for determining the first accepted value include: means for selecting an acceptable window size value from the set of acceptable window size values, said first selected current value ; determining means if the first current selected value is accepted by said at least one first intermediate device; means for activating, in the case of a negative determination, said selection means and said determining means with a first selected value lower than the first selected current value.  Advantageously, the means for determining whether the first current selected value is accepted by said at least one first intermediate device comprise: means for sending to said at least one first intermediate device of a resource allocation request corresponding to the first selected value current, and a window size value is considered to be accepted by said at least one first intermediate device when the manager device receives from said at least one first intermediate device a positive resource allocation report corresponding to the first value selected current.  According to an embodiment of the invention, the management means furthermore comprise: means for determining one or more devices, said device (s) accepting, from among the first device (s) ( s) Intermediate (s), having accepted the first selected current value; means for sending to said device (s) accepting a request for the release of resources corresponding to the first selected current value.  According to an advantageous characteristic of the invention, the management means also comprise: means for selecting at least a second data content, the second content being transmitted between a second source device and a second receiving device on a second transmission path comprising at least a second intermediate device, at least one of said second device (s) intermediate (s) being also one or said first (s) device (s) intermediate (s); means for determining an acceptable window size value, said second acceptable value, for transmitting the second content; Means for sending, to at least said at least one second intermediate device, information representative of said second acceptable value in order to update the transmission of the second content according to a window size equal to said second acceptable value.  Advantageously, a window size value is said to be acceptable for the transmission of a content if it satisfies at least one of the criteria belonging to the group comprising: the window size value is greater than a maximum packet size value of content; 10 - the window size value is greater than a predefined minimum value checking n * MSS, where n is a coefficient dependent on the priority of the content and MSS is a maximum value of packet size of the content - the window size value is greater than a minimum window size for transmission of lower priority content; the window size value is less than a product max_bandwidth * RTT on the content transmission path, where max_bandwidth is the maximum theoretical bandwidth on the content transmission path and RTT is an averaged value of the path's path time of transmission of the content.  The invention also relates to a transmission device (which corresponds to the aforementioned device) comprising means for managing resources for the transmission in a communication network of a data content between a source device and a receiver device on a data path. Transmission comprising at least one intermediate device, said transmission device being one or more of said intermediate devices.  According to the invention, the management means comprise: means for receiving a message comprising a window size value accepted by at least said at least one intermediate device 30 for transmitting said content; Means for determining the position, on the transmission path, of said transmission device; means for sending to the source device of a message, said first initialization message, of initialization of the transmission of the content, said first initialization message comprising the accepted value, said sending means being activated if the transmission device is the receiver device.  Advantageously, the transmission device being distinct from the receiving device, the management means comprise: means for receiving a message, said second initialization message, initialization of the transmission of the content, said second initialization message comprising at least one value indicating a level of resources available on the receiving device for transmitting the content, said value selected; Means for determining whether the value selected is greater than the accepted value; means for modifying said second initialization message, replacing the value retained by the accepted value, said modifying means being activated if the value retained is greater than the value: accepted; means for sending said second initialization message to the source device.  Preferably, the transmission device being distinct from the receiving device, the management means comprise: means for receiving a message, said acknowledgment message, for acknowledging the initialization of the transmission of the content, said message acknowledgment system comprising at least one value indicating a level of resources available on the server for transmitting the content, said value selected; Means for determining whether the value selected is greater than the value accepted; means for modifying said acknowledgment message, replacing the value retained by the accepted value, said modifying means being activated if the value retained is greater than the accepted value; Means for sending said acknowledgment message to the receiver device.  Advantageously, the management means furthermore comprise: means for sending to a management device conforming to a centralized signaling protocol, a message comprising the value selected, in order to allow an update of a size value. accepted window 10 for the data content, said sending means being activated if the value selected is not greater than the accepted value.  According to an advantageous characteristic of the invention, the management means further comprise: means for receiving at least one packet of the content; Means for determining from said at least one received packet a minimum value of window size for the transmission of the content, said lower value; means for sending to a management device, of the lower value, in order to allow an update of a set of acceptable size values for the transmission of the content.  Advantageously, the lower value corresponds to a maximum packet size value of the content.  Preferably, a window size value is said to be acceptable for the transmission of a content if it verifies at least one of the criteria belonging to the group comprising: the window size value is greater than a maximum packet size value of content; the window size value is greater than a predefined minimum value satisfying n * MSS, where n is a coefficient dependent on the priority of the content and MSS is a maximum packet size value of the content 2908577 18 - the size value window is greater than a minimum window size for transmission of lower priority content; the window size value is less than a product max_bandwidth * RTT on the content transmission path, where max_bandwidth is the maximum theoretical bandwidth on the content transmission path and RTT is an averaged value of the travel time of the content. path of transmission of the content.  The advantages of the computer program product, storage medium, manager device and transmission device are the same as those of the previously described resource management method, they are not detailed further.  5.  List of Figures Other features and advantages of the invention will emerge more clearly from the following description of a preferred embodiment, given by way of a simple illustrative and nonlimiting example, and the appended drawings, among which: FIG. 1 shows a diagram of a local area network in which the transmission method according to an embodiment of the invention can be implemented; FIG. 2 shows a diagram of a generic device able to implement the transmission method according to the particular embodiment of the aforementioned invention; FIG. 3 illustrates the principle of the method of transmitting the content c0 according to the particular embodiment of the invention mentioned above in the context of the network 100 of FIG. 1; FIG. 4 shows the steps of an algorithm implemented by a Digital Media Player equipment of the local network when the QosManager implements the method of transmission of OC according to the particular embodiment of the invention; FIG. 5 presents the main steps of an algorithm for obtaining the value of the accepted window size for C0 implemented by the QosManager of the local network in the context of the transmission method according to the aforementioned embodiment of FIG. the invention; FIG. 6 presents the main steps of an algorithm for updating the value of the window size for the transmission of a TCP TCP stream according to a preferred embodiment of the invention.  6.  DESCRIPTION OF AN EMBODIMENT OF THE INVENTION The resource reservation method according to a particular embodiment of the invention is described below in the context of a local network 100 (a diagram of which is illustrated in FIG. 1) which notably comprises equipment complying with a centralized signaling protocol, for example the UPnP QoS protocol.  Of course, the centralized signaling protocol may be any protocol other than the UPnP QoS protocol.  The local network 100 is, for example, a network implementing the IEEE 802 protocol (or any other IEEE 802-type protocol) such as the Ethernet protocol and makes it possible to implement UPnP QoS type communications (at least between certain equipment) for which each UPnP QoS equipment (or equipment implementing the UPnP QoS standard) of the network is identified and periodically communicates the description of its services.  The local area network 100 includes both terminal equipments which are visible to the user (for example, multimedia terminals of the local area network 100 which are directly controlled by the user) and network infrastructure equipments allowing the connection between these terminals. terminal equipment.  It should be noted that the local network 100 may be a home network or a local business network, consisting partially or totally of wireless segments (for example compliant with Wifi or Bluetooth standards, registered trademarks).  The category of terminal equipments comprises in particular: a multimedia stream server 110 corresponding to the UPnP AV standard (also known as UPnP MediaServer) which is notably capable of continuously transmitting video contents according to network protocols and which operates in connected mode (for example via the HTTP protocol over TCP / IP) and / or in unconnected mode (for example via the RTP protocol over the UDP / IP protocol).  This server may especially be a personal computer, a DVD player or a camera having IP connectivity; a client terminal 120, having a UPnP Media Renderer service, which may especially be a personal computer or a TV screen capable of displaying the multimedia streams coming from the server 110; a UPnP control station 160, which can notably be a personal computer, a tablet PC, a personal assistant (or PDA), a remote control offering the user a selection of UPnP equipment 15 on the local network 100 and multimedia contents to play.  The category of network infrastructure equipment includes interconnection equipment 140A, 140B and 140C which can be: level 2 routing equipment, for example switches 20 (or switches in English) which are devices of interconnecting more than two Ethernet segments, according to a routing criterion based on network level 2 (for example Ethernet MAC addresses); bridges between two segments of the network (for example, a computer with two network cards is a bridge).  These network infrastructure equipment 140A, 140B and 140C generally implement QoS protocols such as stream priority management protocols (e.g. IEEE-802 protocol). 1p) or QoS online reservation signaling protocols such as SBM protocol standardized by RFC-2814.  They can also implement the UPnP 30 QoS standard.  A bridge is interconnection hardware that connects two Ethernet segments.  Each of the segments to which a bridge is connected is associated with a table of MAC addresses of the terminal equipments of this segment which is managed by the bridge.  Such a table is constructed by the bridge using a learning process in which, at each transmission of a frame by a piece of equipment, the bridge stores in the table the MAC address of the terminal equipment. look with the segment concerned.  These tables allow the bridge to route the frames.  Indeed, when the bridge receives a frame from its first segment, it relays the frame to its second segment in one of the following cases: the destination address of the frame corresponds to an address of the second segment; it is a broadcast address (or broadcast in English); the address is not known by the bridge.  A switch is considered a bridge that has more than two interfaces.  Services conforming to the UPnP QoS standard (such as QosDevice, QosPolicyHolder or QosManager) may be embedded in some of the LAN 100 equipment (as indicated in the UPnP QoS standard).  The UPnP QosDevice services are embedded in particular on the interconnection devices 140A, 140B and 140C of FIG. 1, but are also supported by the server 110 and the client terminal 120 (or the first 120A and second 120B client terminals of FIG. 3).  Furthermore, the local network 100 comprises a unique UPnP QosManager service which is for example embedded in a device 150 which is hereinafter referred to as QosManager 150 (otherwise called a management device in the context of the resource reservation).  However, this

  UPnP service QosManager can be embedded in any equipment of the local network 100 preferably having a hardware platform identical to that of the generic equipment 200 described hereinafter with reference to FIG. 2.  The UPnP QoS standard further defines the procedures for selecting the active QosManager maintainer if multiple services are competing.  In the following, the transmission method according to the particular embodiment of the invention mentioned above is described in a particular example of the transmission, according to the T'CP protocol, of a multimedia content (or stream) cO on a path. transmission between a source device (media stream server 110) and a receiving device (client terminal 120 or the second client terminal 120B of FIG. 3) belonging to the local network 100.  Of course, the transmission method according to the invention applies to the context of any other burst transmission protocol such as the LLC-2 protocol (according to the IEEE 802 standard. 2) which provides an ARQ transmission service for the common IEEE MAC level link sublayer (802. 3, 802. 4, 803. 5 ,. . . or HDLC, for High-Level Data Link Control, which is an OSI layer-level 2 protocol used to support communication protocols such as H. 323, V. 120 or X. 25.  Thus, during the selection of the content cO by a user via the control station 160, a message 180 (for example a RequestTrafficQos message conforming to the UPnP-QoS protocol, message hereinafter designated by RequestTrafficQos) is sent to the QosManager 150 in view to warn the type of media content cO to receive and prepare the QoS resources necessary for the proper routing of the content cO between the media stream server 110 and the client terminal 120 (or the second 120B client terminal of Figure 3).  Next, the QosManager 150 seeks to obtain the path of transmission of OC across the network, in order to determine which QosDevice equipment to inform of the reservation of resources to be made for the transmission of the OC content (confirmation of the QoS parameters of the content cO by sending to the QosDevice equipment a SetupTrafficQos message 181 in accordance with the UPnP QoS protocol hereinafter designated by SetupTrafficQos).  If all QosDevice devices present on the c0 transmission path (eg including QosDevice 140A through 140C) accept the QoS characteristics of the c0 content, the QosManager 150 will acknowledge (or acknowledge receipt of) the request from the control station 160 and the latter will allow the client terminal 120 (or the second client terminal 120B of FIG. 3) to play the multimedia content c0 (for example by means of an Avt_Play message 182 in accordance with the UPnP AV protocol, hereinafter designated message. by Avt_Play).  The client terminal 120 (or the second client terminal 120B of FIG. 3) will then send a request to read the multimedia stream to the stream server 110 (for example by means of a message of the RTSP type in order to receive the multimedia stream at the same time. RTP broadcast format or via an HTTP request to directly access the multimedia resource).  In the case of transmission, c0 content according to the TCP protocol (the control station 160 provides a content access URL by implementing the HTTP protocol), an HTTP GET request is issued from the client 120 (or the second client terminal 120B of FIG. 3) to the server 110.  The opening of this TCP connection follows the steps in accordance with the TCP standard described in Annex 1 (SYN 191 messages and SYN-ACK 192 message).  The content transmitted subsequently is noted 190.  The transmission method according to the invention (described in more detail in connection with FIGS. 3 to 6) is implemented in the form of software and / or a plurality of sub-software (including a plurality of algorithms described below) which is (are) executed in one or more machines of the local network 100, for example in the QosManager 150.  FIG. 2 shows a diagram of a generic device 200 able to implement the method of transmission of CO according to the particular embodiment of the invention mentioned above.  For example, the aforementioned QosManager 150 in relation to FIG. 1 is identical to the generic device 200 described in relation to FIG. 2.  This generic device 200 may in particular be connected to any means of storing images, videos, or sounds connected to a graphics card and delivering to the generic device 200 multimedia data.  Thus, the generic device 200 comprises a communication bus 202 to which are connected: a central processing unit 203 (which is for example a microprocessor referenced CPU); a read-only memory 204 referenced ROM, which may comprise the aforementioned software (s) and referenced (s) Prog; a RAM 206 (RAM referenced cache memory), including registers adapted to record variables and parameters created and modified during the execution of the aforementioned software (s); a screen 208 for viewing data and / or to act as a graphical interface with the network administrator who can interact with the software (s) according to the invention, using a keyboard 210 or any Other means such as a pointing device, such as for example a mouse 211 or an optical pen; a communication interface 218 connected to a distributed communication network 220, for example the local network 100, the interface being able to transmit and receive data.  The generic device 200 also includes (but this is optional): a hard disk 212 which may include the software (s) Prog; a diskette drive 214 adapted to receive a floppy disk 216 and to read or write to it data processed or to be processed in accordance with the resource reservation method according to the invention.  Of course, instead of the floppy disk 216, it is possible to implement any information medium that can be read by a computer or by a microprocessor, whether integrated or not, possibly removable, is adapted to store the software (s) ) according to the invention (for example, a compact disc (CD-ROM) or a memory card).  The communication bus 202 allows communication and interoperability between the various devices included in the generic device 200 or connected to this equipment.  More generally, by virtue of the communication bus 202, the central unit 203 is able to communicate instructions to any device included in the generic device 200 directly or via another device of the generic device 200.  The executable code of each of the above-mentioned software (s) enabling the generic device 200 to implement the resource reservation method according to the invention can be stored, for example, in the hard disk 212 or in the memory dead 204.  The central unit 203 controls and directs the execution of the instructions or portions of software code of the software (s) according to the invention.  When powering on, the software or software that is stored in a non-volatile memory 15 (for example the hard disk 212 or the read-only memory 204), are transferred into the random access memory 206 which will then contain the executable code of the one or more software (s) according to the invention, as well as registers for storing the variables and parameters necessary for the implementation of the resource reservation method according to the invention.  FIG. 3 illustrates the principle of the content transmission method c 0 according to the particular embodiment of the invention mentioned above in the context of the network 100 of FIG. 1.  In the context of this FIG. 3, the client terminal 110 of the network 100 illustrated in FIG. 1 is replaced by the first client terminal 120A and the second client terminal 120B.  In the following, it is assumed that a content 190 is already in transit between the first client terminal 120A and the multimedia flow server 110.  The control station 160 informs the QosManager 150 of a QoS establishment request according to precise characteristics (by means of the steps 401 to 405 of the algorithm 30 hereinafter described in connection with FIG. 4) for the introduction. a multimedia content cO compliant with the TCP protocol to be transmitted from the server 110 to the second client terminal 120B.  These QoS characteristics are previously obtained by the control station 160 by the description of the media cO offered by the UPnP MediaServer 110 as described below in relation to FIG. 4.  In a step 1, a request (or message) RequestTrafficQos 301 is sent from the control station 160 to the QosManager 150.  On detecting that the new content cO is of type TCP, the QosManager 150 determines an acceptable initial value of TCP window size (or TCP window size) for the content c0 according to the characteristics of cO that are specified in the TSPEC structure contained. in the RequestTrafficQos request.  A window size value is said to be acceptable for transmission of content if it verifies at least one of the criteria belonging to the group comprising: the window size value is greater than a maximum packet size value of the content, called MSS; the window size value is greater than a predefined minimum value (n * MSS), where n is a predetermined coefficient depending on the priority of the stream; the window size value is greater than a minimum window size for a content of lower priority (in proportion to their bit rate); that is, a higher priority stream will be privileged in the resource allocation related to the window size; the window size value is less than a max_bandwidth * RTT product on the path, where max_bandwidth is the maximum theoretical bandwidth on the network link and RTT is an averaged value of the RTT parameter (for Round Trip Time) or time of the path of transmission.  As explained in TCP schedule 1, the value of the initial TCP window size determined at the opening of the connection corresponds to the maximum size of data transmitted in one or more burst for a given stream before return of an acknowledgment of reception of the data by the receiving device.  This value is directly applied to a reserved memory size for TCP content.  The choice of this memory value is crucial.  In the state of the art, this value is dissociated from any memory resource consideration available on the network.  The transmission method according to the invention aims at calculating an ideal initial window value according to the characteristics of the stream cO to be transported, then possibly adapting (or adjusting) this value to the environmental conditions of the network so as to obtain an accepted value (defined below).  In general, a memory size (or Buffer_size) follows the following formula: Buffer_size = bandwidth * delay (1) or: Buffer size = bandwidth * RTT (2) 15 where bandwidth is the bandwidth and delay is the maximum time elapsed between the transmission of data by the source device and the reception of its acknowledgment.  The value of the RTT (for Round Trip Time) parameter is easily obtained, for example, by sending a ping message, and is deterministic on the local network 100.  In a step 2, the QosManager 150 initiates a negotiation (which will be detailed below in connection with FIG. 5) of the value of the window size for cO with all the intermediate QosDevices (in this case the devices 140A, 140B and 140C) present on the path of transmission of the stream OC 25 between the media stream server 110 and the second client terminal 120B.  To do this, it sends each of them a SetupTrafficQos 302 message (and possibly an AdmitTrafficQos message from the UPnP QoS protocol).  As part of this negotiation, the QosManager 150 is able to modify the characteristics of the OC flow proposed by the control station 160.  Indeed, the TSPEC structure serves to include information such as bit rate (or bit rate) in bits per second (or bps), latency (in ms), jitter (in ms), and / or traffic classification (eg game, audio, video, etc. . . ).  Examples of fields of the TSPEC structure useful in the context of the present invention are given below: Maximum burst size (or maximum burst size in bytes): supports the exchange of the calculated TCP window value step 1, giving the limit of the packet transmission burst of the server; - Maximum Packet Size (or maximum packet size in bytes): supports the exchange of the TCP MSS field value (cf.  Appendix 1) when it will be known (after establishment of the connection), giving the minimum limit that the TCP window must not cross.  It will be seen later that this value will be useful in the algorithms for adjusting the value of the window size of an existing stream; MeanDatarate (or average bandwidth in bits / sec): Supports the bandwidth indication of the video stream, which is generally obtained by the control station 160 on information provided by the server 110, as stipulated in the UPnP AV standard. .  In a step 3, each interconnection device 140A-140C comprising the UPnP QosDevice UPnP service QoS checks its operating state (in particular, its congestion state).  Thus, a given intermediary device of the transmission path may possibly warn the QosManager of an inability to carry out the QoS policy recommended by the QosManager 150.  In this case, the QosManager 150 discovers that resources are missing, and it then looks for among the streams that pass through the given device, the stream or streams to degrade (for example the stream 190) whose QoS can be reduced.  The reduction policy can for example be based on priority management between the streams, and / or the available adjustment (difference between the initial window value which remains the maximum, and the value of the TCP MSS field which is the minimum 30 ).  For example, the media stream 190 is detected as a TCP stream to be degraded (or can be adjusted) to allow the introduction of another competing stream (the cO stream being admitted).  In a step 4, once the streams to be degraded have been identified, the QosManager 150calculates the new TCP window size values for those streams to be degraded, and the new window size value for the current OC stream. admission.  Then, for each stream being transmitted to update (whose stream 190), and for the stream cO being admitted, the intermediate QosDevices 10 of the transmission path of this stream (for example the QosDevices 140A to 140C for stream cO) each receive, in a SetupTrafficQos message 302, a new window size value for that stream.  In the case of the second client terminal 120B (concerned with the transmission of the stream OC), for each stream being transmitted to update (whose streams cO and 190), the QosManager 150 supplies the determined window size value. for this flow to the second client terminal 120B.  To do this, two possibilities according to the invention detailed below are offered.  The first possibility according to the invention is to return this new value to the control station 160 in return for the message RequestTrafficQoS 20 301 that the control station 160 has previously sent to the QosManager 150.  The control station 160 is then in charge of transmitting this new value to the second client terminal 120B via a message 303 conforming to the UPnP AV standard (for example a PrepareForConnection message, or a SetAvTransportUri message or an Avt_Play message). .  This first possibility implies that the body of the UPnP AV messages dedicated to this transmission must be modified and that these messages therefore no longer conform to the UPnP AV standard.  The second possibility according to the invention is preferred in the context of this particular embodiment because it respects the UPnP standards in place.  It consists in the QosManager 150 directly informing the second client terminal 120B of the new window size value chosen through the TSPEC structure embedded in the body of a SetupTrafficQos message 304 (according to the Application Programming Interface or UPnP API). QosDevice).  Once informed of the chosen TCP window value according to the capabilities of the interconnection equipments 140A to 140C of the transmission path, and upon receipt of the Avt_Play message 303 from the control station 160, the second client terminal 120B activates, by means of a message 305, the creation of the TCP connection towards the server 110.  This activation is carried out by indicating the new TCP window size value in a TCP SYN 305 message instead of the conventional value proposed by the operating system running the software and / or the plurality of sub-software of the aforementioned invention. (s).  After establishment of the connection, the value of the TCP MSS field of the TCP SYN message is obtained by the second client terminal 120B which stores it for transmission to the QosManager 150.  According to the invention, the second client terminal 120B can send alert messages 306 (UPnP notifications or events) to the QosManager 150 in the following cases: if the new value of the TCP window size received in the message 20 If the TCP SYN acknowledgment from the server 110 is less than the original, it is important to adapt the QoS reservations so as not to allocate resources in the 140A to 140C interconnection equipment that will never be used; to inform of the value of the TCP MSS field resulting from the connection: the QosManager thus knows the minimum buffer size for a TCP packet, and thus it can adjust the size of the TCP window so that it is equal to n * MSS, where n is an integer greater than or equal to 1.  In the case of the first client terminal 120A (concerned with the transmission of the stream 190 to be updated), for each stream being transmitted to be updated (including the stream 190), the QosManager150 informs the customer 120A of the new 2908577 31 value of window size.  Thus, for example, QosManager 150 directly informs the first client terminal 120A of the new window size value chosen by incorporating this new value in the Maximum Burst Size field of the TSPEC descriptive structure of the flow of a SetupTrafficQos message 307.  In order to apply this new window recommendation, the first client terminal 120A must implement an algorithm 308 for adjusting or adjusting the value of the window size of the stream for controlling the flow.  For this purpose, the first client terminal 120A may for example implement one of the two following solutions.  In a first solution according to the invention, the first client terminal 120A dynamically modifies the value of the window size TCP advertised window (also called acknowledge-window) in an acknowledgment packet (or ACK for acknowledgment) returned to the server 110.  Indeed, as indicated in Appendix 1, according to the TCP protocol, each segment header contains an instant window field called advertised-window which specifies how many additional bytes of data the client is willing to accept.  An important fact about TCP is that the server is not allowed to send more bytes than is specified in the advertised window.  Thus, this value indicates to the server a limit for the transmission, and can be assimilated to the memory size that the client is able to receive.  In theory, the TCP protocol provided that this value could be zero, in which case sending another ACK packet called window update would be necessary to announce that the client is ready to receive the data.  In practice, this will not happen with the present invention because the initial value of the TCP window is already correlated with the QoS resources of a previous state of the network.  In order to reduce / increase the server throughput, the client modifies the advertised window value according to the following formula: 30 new_advertised_WD = advertised_WD - (initWD - updateWD) 2908577 32 where: - initWD is the maximum value of the window (initial value negotiated at connection establishment); - updateWD is the new maximum value of the specified window; 5 advertised_WD is the theoretical availability value in the receiver buffer (less than or equal to initWD); - new_advertised_WD is the value to be sent in the advertised window acknowledgment packet.  In a second solution according to the invention, an ECN (Explicit Congestion Notation) field is implemented in the header of a TCP message.  The implementation of the ECN field improves the performance of the TCP protocol.  Indeed, when a router or switch equipment detects the occurrence of congestion (before the entire buffer is filled), this equipment has the possibility to indicate the congestion by positioning the Congestion Experienced or CE code in the Explicit Congestion field Notification of the IP frame header (in accordance with RFC3168).  One of the advantages of using the ECN field is that it avoids the unnecessary loss of packets for time-sensitive TCP connections (such as for example streaming video connections).  The ECN protocol also makes it possible to avoid timeouts (or delays) TCP for retransmission.  Thus, when this field is set, it indicates congestion and the server regulates its transmission rate more slowly: it no longer increases the transmission window 25 cwnd.  The first client terminal 120A has the possibility of marking this bit when it detects that the value of the dynamic TCP window cwnd approaches the new threshold which has been indicated to it.  With reference to FIG. 4, the steps of an algorithm implemented by a Digital Media Player equipment of the local network 100 in accordance with the invention are presented when the QosManager 150 implements the transmission method 2908577. according to the particular embodiment mentioned above of the invention.  Media Player equipment is a device with application programs capable of playing multimedia content (both audio and video).  In Digital Living Network 5 Alliance (DLNA) terminology, DMP (Digital Media Player) equipment belongs to an equipment class that includes Control Point (UPnP) and Local View (UPnP) features. MediaRenderer).  For example, in the context of a particular mode of implementation of the invention, the Digital Media Player equipment hereinafter referred to as DMP equipment is constituted, at least in part, by the control station 160 and the terminal. client 120 (or at least one of the first and second client terminals of FIG. 2) of the local network 100 of FIG.  For example, this Digital Media Player is architectured in much the same way as the generic device 200 of FIG.  The actions performed by the DMP equipment according to the invention, when receiving a command from the user for the local display on the client terminal 120 of the TCP compliant media stream cO and selected on the server 110 remote, are presented below.  In a step 400, the DMP equipment (as a control station 160) receives an internal command presenting the selection by the user from a graphical interface of the multimedia content cO located on the server 110.  For the sake of simplification, it will be assumed that the access protocol to this content is of type HTTP over TCP.  In a step 401, the DMP equipment gathers the information relating to the multimedia stream cO made available by the server 110.  This information was previously obtained by sending one or more Browse requests as specified by the UPnP AV standard for the CDS or ContentDirectoryService service.  According to this same standard, the responses given by the server 110 contain in particular a resource field res specifying the type (or version) of the transport stream for c0 and certain elements such as the necessary bandwidth.  There is a resource field by type (or version) of transport stream for the multimedia content cO, knowing that the server 110 can offer different versions of this content cO according to for example quality criteria.  According to the convention, the list of resource fields is ordered in order of decreasing priority according to the wishes of the server 110.  In practice, the first descriptions correspond to the best resolutions of the multimedia content cO, and therefore to stricter QoS criteria.  The DMP equipment selects a resource field for cO.  In a step 402, the selected resource field is parsed to format the QoS criteria for the cO stream in the TSPEC structure of a RequestTrafficQoS message to be sent to the QosManager 150.  In a step 403, the DMP equipment checks whether it receives an acceptance response from the QosManager 150.  In a step 404, if the DMP equipment does not receive acceptance of the QosManager 150, then it checks whether it is possible (depending on the capabilities of the network) to implement other type (or version) of Transport flow for OC, each associated with a resource field.  If it is possible (depending on the capabilities of the network) to implement other type (or version) of transport stream for cO, then in a step 405, the DMP equipment selects another resource field for cO among the resource fields associated with these types of transport streams.  Then, step 402 is again implemented.  If it is not possible (depending on the capacity of the network) to implement other type (or version) of transport stream for o, then in a step 409, it is terminated. algorithm.  If the DMP equipment receives an acceptance of the QosManager 150, then, a step 406 is implemented.  According to the aforementioned embodiment of the invention, the Digital 2908577 Media Player equipment also includes a UPnP QosDevice service.  Through the implementation of this QosDevice service, in step 406, the DMP device receives a SetupTrafficQos message by which the QosManager 150 indicates to the DMP equipment the QoS parameters of the c0 stream that have been negotiated (at the same time). by means of the obtaining algorithm hereinafter described in connection with FIG. 5) by the QosManager 150 on the local network 100 with all the intermediate QosDevices 140A to 140C of the c0 transmission path between the server 110 and the equipment DMP (as client terminal 120) implementing the present algorithm.  It should be noted that the information sent in this SetupTrafficQos message is more accurate than the original information retrieved by the DMP equipment (as a checkpoint 160) in steps 401 and 405.  This structured information in the TSPEC structure includes the value of the accepted TCP window size to use when opening the TCP connection (Maximum burst size field) for the transmission of c0.  This value is stored in the internal memories of the DMP equipment and is written maxWI) in the sense that this value of the accepted window size is a maximum that must never be exceeded because the connection is parameterized on this device. value.  According to a variant of the above-mentioned embodiment of the invention, the DMP equipment does not integrate a QosDevice UPnP service (and therefore does not receive a SetupTrafficQos message in step 406).  In this case, the value of the maxWD accepted window size is obtained in response to the RequestTrafficQoS message sent to the QosManager 150 by the DMP equipment (as a checkpoint 160).  It should be noted that this variant is not privileged in the sense that it is not standard to the UPnP QoS protocol.  The algorithms for determining the value of the accepted TCP window size maxWD proposed by the QosManager 150 will be explained hereinafter with reference to FIG. 5.  On receipt of an internal command from the local graphical interface to play the stream OC, in a step 407, the DMP device (as a client terminal 120) opens a TCP connection with the server 110, specifying the maxWD value in the TCP SYN segment.  According to another variant of the aforementioned embodiment, the activation of step 400 explicitly implies the request of the user to play the selected multimedia content cO.  In this case, the activation of step 407 is direct.  At the end of the TCP connection phase, in a step 408, information relating to this TCP connection is sent by the DMP equipment to the QosManager 150.  This information is for example the value of the size of the TCP window modified for the transport of the stream cO (indeed, it happens that the server 110 lowers the accepted value specified by the QosManager for the client terminal 120) and the value MSS of this connection.  This information can be rendered in response to the SetupTrafficQos message, or by a UPnP event provided by the UPnP QosDevice service.  In all cases, the maxWD value should reflect the TCP window value negotiated by the TCP connection establishment phase, and this value is stored locally in the TSPEC structure describing the current stream cO (Maximum Burst size field).  Similarly, the MSS value is stored in the Maximum Packet Size field of the TSPEC structure associated with the cO stream.  This TSPEC structure is accessible for the QosManager 150 through the UPnP GetQosState action, which is responsible for providing information on the active flows transiting on the equipment supporting the QosDevice service, as specified in the UPnP QoS standard.  Then, in step 409, the algorithm is terminated.  In relation to FIG. 5, the main steps of an algorithm for obtaining the value of the accepted window size (hereinafter referred to as maxWD) for cO implemented by the QosManager 150 of the local network 100 are presented. in the context of the transmission method according to the aforementioned embodiment of the invention.  For information, it is recalled that according to the UPnP QoS standard, the QosManager service can be located in any equipment of the local network 100.  In the context of this particular embodiment of the invention, the QosManager service is located in the QosManager 150 of the network 100 of FIGS. 1 and 3.  According to a particular embodiment of the invention, the QosManager can be confused with the DMP equipment of FIG. 4.  The algorithm corresponding to the steps of this FIG. 5 implemented by the QosManager 150 aims to calculate the size of the TCP window for the transmission of the new stream cO on its transmission path, to keep the information relating to the current connection of this flow cO, and possibly to adapt the QoS of the existing flows for the admission of this new flow cO.  The user selects the content cO from the control station 160.  Then, according to the UPnP QoS standard, the control station 160 decides on a type of transport stream for the TCP compliant multimedia content to be communicated between the UPnP MediaServer server 110 and the client terminal 120 (FIG. FIG. 1) or the second client terminal 120B (FIG. 3), the latter being of UPnP MediaRenderer type.  In a step 500, the QosManager 150 receives a RequestTrafficQoS message from the checkpoint 160, by which the checkpoint 160 requests the QosManager 150 to establish a QoS policy for the media flow cO, especially at the QosDevice level of the path of transmission of CO.  The standardized RequestTrafficQoS message contains information on the nominal characteristics of the stream cO as well as the destination and source of the stream (the UPnP QoS standard describes the XML structure called TrafficDescriptor characterizing this stream cO, containing the previously specified TSPEC elements).  An example of a TrafficDescriptor structure received in the RequestTrafficQos message is presented in connection with Appendix 2.  In a step 501, following receipt of the RequestTrafficQos message, the QosManager 150 detects the type of media (eg, picture, video, sound,. . . ) and the protocol implemented for access to co (for example the FTP protocol, http protocol ,. . . ) to particularise the selected cO stream.  Indeed, in a preferred embodiment of the invention, it is preferred to propose priorities for the management of flows such as the flow cO.  UPnP QoS states that, following the receipt of the RequestTrafficQos message, the QosManager 150 queries the QoS UPnP service named QosPolicyHolder on LAN 100 to obtain the local QoS management policy.  This results in obtaining a traffic type classification number called Traffic Importance Number (or TIN).  This classification corresponds to a typing classification of multimedia content (audio data, game, audio / video data, image).  However, it is possible to refine this characterization by taking into account the type of access protocol to the resource (HTTP, FTP) in order, for example, to favor data in streaming mode (via 15 HTTP) from those in download mode (via FTP), the latter having no real time criterion for the broadcast.  Steps 502 and 503 hereinafter detailed constitute an initialization phase of the value of the initial window size for cO on the transmission path of cO.  In a step 502, following the information provided in the RequestTrafficQos message by the control station 160, on the average rate of the source (the server 110), it is possible to deduce an estimate of the value of the TCP window size. initial named DefaultWD (thanks to the formula (1) described in step 1 previously described in connection with Figure 3) of cO.  In a step 503, the QosManager calculates a modulated window size value of c0, hereinafter referred to as InitWD, according to the formula: InitWD = DefaultWD × coeff (TIN) where coeff (TIN) is a function of the characteristics of the flux cO (of which the classification number of the TIN traffic type) and the QoS policy of the local network 100 discovered in the previous step.  It should be noted that, according to a variant of the particular embodiment mentioned above, the step 503 for calculating the modulated InitWD value is not implemented and the rest of the algorithm uses the DefaultWD parameter instead of the InitWD parameter. .  Following the initialization phase of the value of the initial window size of c0, in a step 504, the QosManager 150 obtains the transmission path of the stream c0.  It thus obtains the list of intermediate QosDevice equipments (that is to say, in this case, the interconnection equipments 140A to 140C), between the server 110 and the client terminal 120 (FIG. 1) or the second terminal. client 120B (FIG. 3), through which the content c0 passes.  Thanks to the information received from the GetPathlnformation request, the interconnection equipments 140A to 140C are considered as part of the list of these intermediate QosDevice equipments.  It should also be noted that the QosManager 150 is also able to detect whether the client terminal 120 (FIG. 1) or the second client terminal 120B (FIG. 3) concerned by the stream c0 has the service QosDevice.  For each of the intermediate QosDevices (on the transmission path of the stream c0), all or some of the steps 505 to 517 described below are applied.  In a step 505, the QosManager checks whether a current QosDevice among the intermediate QosDevices has not been queried about QoS admission.  If all the QosDevices of the transmission path have been tested (with a step 506 hereinafter described) then a step 520 hereinafter described is implemented.  If a current QosDevice is to be queried, then, for this current QosDevice, in a step 506, the QosManager 150 tests whether it accepts the admission of the new c0 stream with the QoS properties updated by the QosManager 150 during previous steps.  For this, a SetupTrafficQos message is sent to the current QosDevice and this message includes the calculated InitWD value (at step 503) in the Maximum Burst Size field of the message's TSPEC structure.  An example of such a TSPEC structure is given in Appendix 3.  According to a variant of the above-mentioned particular embodiment of the invention, instead of the SetupTrafficQos message, an AdmitTrafficQos message is sent instead when the QosDevice services are compatible with the version 3 of the UPnP QoS standard.  In a step 507, the QosDevice 150 checks whether the current QosDevice accepts the proposed QoS characteristics for the cO stream.  If the current QosDevice does not accept the QoS characteristics proposed for the flow cO, then a step 510 hereinafter described is implemented.  If the current QosDevice accepts the proposed QoS characteristics for the stream, then, in a step 508, the InitWD value is considered accepted.  Then, in a step 509, the value InitWD for cO and for the current QosDevice is stored in a admittedWD variable belonging to a list L of window size values for admittedC (admittedWD) by the QosDevices 15 of the OO transmission path. .  Then step 505 is implemented.  Thus, if a given QosDevice does not accept the QoS characteristics proposed by the QosManager 150 for the cO flow, then the algorithm enters a phase of adaptation (or adjustment) of the values of the size of the windows of the flows passing through the Given QosDevice (corresponding to steps 510 to 518 hereinafter: 20 described).  Thus, in step 510, the QosManager 150 stores the InitWD value in a admittedWD variable.  The following operations are based on the determination of the admittedWD value corresponding to the memory resources granted by the given QosDevice equipment for the OC flow to be admitted.  This value is first initialized by the value of the ideal initWD window size which must then be reduced.  Preferably, for the purpose of optimizing the procedure for calculating the value of the size of the window, as the arrival at step 510 is relative to an iteration (step 505) of the QosDevices of the transmission path the value assigned to step 510 may be that determined during the previous iteration relative to the previous QosDevice tested.  Following step 510, in a step 511, the QosManager 150 selects, from among all the streams referenced by and which pass through the given QosDevice, the flows to be degraded.  Each stream to be degraded is associated with a transmission path of the stream to be degraded which

  goes through the given QosDevice. A stream to degrade a stream that checks at least one criterion. It is assumed in the following, for example, that the criterion is the priority. Thus, preferentially, the QosManager 150 detects the lower priority streams than the new stream c0 to be admitted (for example, these priorities are in particular based on the criteria used by the steps 501 and 502 mentioned above). These lower priority streams are called streams to degrade. For each stream to be degraded, the QosManager 150 raises the current value of the TCP window size named currentWD and the minimum value MSS of the stream c0 at the given QosDevice. In a step 512, for each stream to be degraded, the QosManager 150 calculates an updatedWD value that replaces, for the stream, the currentWD TCP window size at the given QosDevice. The updatedWD window size is reduced compared to the currentWD window size. For example, a QoS reservation degradation policy for a stream may be relative to the classification of this stream (for example, a video stream may be reduced by 5% per each iteration of a reduction attempt), knowing that the maximum reduction limit corresponds to the MSS value. It is also conceivable to associate a different reduction limit according to the classification of the UPnP QoS stream (for example this limit is k * MSS, or k = 1 for a download of data such as multimedia files, k = 2 for video streaming, k = 3 for audio streaming, etc ...). Preferably, if there is little margin for degrading the currentWD window sizes of the streams to be degraded, in a step 513 the QosManager 150: 30 lowers the admittedWD value for the new stream c0 at the given QosDevice 2908577. In order to test the availability of resources on the given QosDevice according to the new calculated values updatedWD for the window sizes of the streams to be degraded, we update all these flows to degrade before being sure that the given QosDevice can provide the QoS required. To avoid having to update each of the streams to be degraded before being sure that the given QosDevice can provide the required QoS, a step 514 provides for requesting, in advance, the given QosDevice if it can provide the difference between the resources already allocated and those which will be thereafter, a difference which is subsequently called the margin to be tested. Indeed, although the request at step 506 exceeded the total memory capacity of the given QosDevice, and therefore had the effect of leading to the execution of this adaptation phase of the algorithm (steps 510 to 518). ), it is possible that there is a margin of resource availability in the given QosDevice 15 between those currently reserved (for all flows that pass through the given QosDevice) and the total memory capacity of the given QosDevice. Thus, in step 514, the QosManager 150 calculates a testWD value which corresponds to the margin to be tested and is equal to the sum of the updatedWD values for each of the streams to be degraded, to which the admittedWD value is added for 20cO and to which subtract the sum of the currentWD values for each stream to degrade. If the value of the testWD field is zero, then it means that the admittedWD value for the new cO stream should only be obtained from the degradation of the flow passing through the given QosDevice (which means that the given QosDevice is close to the congestion). In a step 515, if the testWD value is not zero, the QosManager 150 sends an AdmitTrafficQos admission request for a dummy stream associated with a value of the window size which is the testWD value. This makes it possible to determine whether the window size values for all the flows passing through the given QosDevice, previously calculated, fall within the memory resource availability margin of the given QosDevice. In the algorithm considered, for the sake of simplicity of description, this request is immediately followed by a request for termination because the flow is fictitious.

However, one alternative is to send a request for termination to a QosDevice only if the allocation request has been rejected by at least one other QosDevice on the transmission path. In this case, the flow description does not correspond to a fictitious flow, but to the data flow cO. That is, once a QosDevice accepts a window size determined to be acceptable for transmission of content, the associated resources are now reserved by the QosDevice for transmission of that content, and will remain so until an actual connection is established between the source device and the content receiving device, unless at least one other QosDevice on the content transmission path rejects that value. In this case, the reservation is canceled and a new iteration can be set up, by selecting a new acceptable window size for transmitting the content, this window size being smaller than the previously tested window size, or by a further step of degrading the data flow transmissions already in place, so as to increase the resources available on the transmission path of the stream to be set up and thus promote the establishment of a connection for this new stream. In a step 516, the QosManager checks whether the given QosDevice accepts the proposed QoS characteristics for the dummy stream. If the given QosDevice accepts the proposed QoS characteristics for the fictitious flow (positive result of the fictitious flow admission request), then in step 509, the QosManager 150 stores the admittedWD value for cO associated with the QosDevice given in the list L. Then the algorithm leaves the adaptation phase of the values of the size of the windows of the flows transiting through the given QosDevice.

Preferably, during the execution of step 509 after the test 516, the list of fluxes to be degraded is also kept in the list L for the given QosDevice, so that this information is subsequently used in a step 521 hereinafter described. If the given QosDevice does not accept the proposed QoS characteristics for the fictitious flow (negative result of the fictitious flow admission request), then in a step 517, the QosManager 150 checks whether it is possible to reduce (s) there is a margin of decrease) the values admittedWD (value of the window size for cO) and / or each of the values updatedWD (window size values of the streams to be degraded).

If such a reduction of the value (s) admittedWD and / or updatedWD is possible, then step 512 is again implemented with these reduced values. In the opposite case, the algorithm stops in a step 526 after the QosDevice has sent, in a step 518, an error report to the control station 160. As indicated above, after the test 505, if all the QosDevices of the transmission path have been tested (with step 506), then step 520 is implemented. This ensures that a value of the window size has been found for the new cO stream in each of the QosDevices of the transmission path, and that, where appropriate, degraded streams transiting QosDevice of the transmission path have suffered a reduction in QoS resource allocation. In step 520, the QosManager 150 obtains the minimum value of all admittedWD values for c0 from the list L of the values allowed by each of the QosDevices of the OC transmission path. This minimum value, hereinafter referred to as maxWD or accepted window size value for cO, is representative of the maximum QoS resources that the QosDevice of the OC transmission path can accommodate for the new cO stream. The maxWD value is used as a basis for the following calculations and in particular for those of step 521.

2908577 In a step 521, from the list L, the QosManager 150 calculates for each QosDevice of the transmission path of cO, and for each stream to be degraded, a new value updatedWD taking into account the maxWD value. So that the QosManager 150 can more quickly find all 5 QosDevices to be updated, there can be memorization of the OO transmission path QosDevices detected during the step 504. This step is almost similar to the step 512, with the difference that we know the final reduction goal for each flow to degrade. Thus, each stream to be degraded is associated with a new value of QoS resource reduction updatedWD. Each updatedWD value is kept in the internal memory of the QosManager 150 to keep track of the active windowing value for each flow with which it is associated. In a step 522, for each stream to be degraded, the QosManager sends a command to update the QoS parameters for the streams to be degraded (for example by means of a SetupTrafficQos message with the value updatedWD calculated in step 521 for this flow) at each QosDevice on the transmission paths of the streams to be degraded (indeed, thanks to the UPnP QoS standard, the QosManager 150 keeps a list of the QosDevice equipments concerned by the transit of a particular stream). For example, in the case of FIG. 3, if a stream to be degraded passes through the switch 140E and also by other switches not shown in FIG. 3, assuming that this stream to be degraded must be updated, the update command is to be sent to all QosDevices where this stream to be degraded transits (including 140B).

Then, in a step 523, the QosManager 150 sends, to all QosDevices of the OC transmission path, a SetupTrafficQos QoS Setup message including the maxWD value (or accepted window size value for cO) in the MaxBurstSize field of the TSPEC structure of this UPnP message.

Preferentially, the client terminal 120 (FIG. 1) or the second client terminal 120B (FIG. 3) supports the UPnP service QosDevice, and therefore the SetupTrafficQos message of step 523 enables step 406 of FIG. FIG. 4. Similarly, for each stream to be degraded, the SetupTrafficQos message of step 522 for updating a window value for that stream to be degraded is also received by terminal equipment. client at the end of the transmission path of the stream to be degraded. Thus, at least one of the first and second possibilities according to the invention described in step 4 of FIG. 3 for the provision, to this client terminal type equipment, of the new window size value for this stream to degrade is then implemented. According to a variant of the present preferred embodiment, the client terminal 120 (FIG. 1) or the second client terminal 120B (FIG. 3) does not support the UPnP service QosDevice, and then the maxWD value is transmitted by return voice to the signaling station. control 160 (step 524).

The control station 160 will then be in charge of indicating this value in an UPnP AV message (such as Avt_Play) sent to the client terminal 120 (FIG. 1) or to the second client terminal 120B (FIG. 3) in order to activate step 406 of the algorithm of FIG. 4. In response to the actions performed in step 408 of FIG. 4, the QosManager 150 is notified, during a step 525, of additional parameters relating to the TCP connection. opened by the client terminal 120 (FIG. 1) or the second client terminal 120B (FIG. 3). These parameters will be useful for the rest if there is a need to modify the QoS parameters as described in step 512.

Then, in step 526, the algorithm is terminated. Improvements can be made to this algorithm. Thus, it can be seen that the admission of a stream during a large load of the network results in a lower maxWD value, and that this value is not revised upwards when the conditions improve. This behavior may for example: be reconsidered by modifying step 520 in order to add the preservation of the value deemed ideal for the flow, and when the disappearance of an existing flow, by carrying out an analysis (substantially identical to that of steps 510 to 514) to increase the QoS resources of certain streams with the limit of the idealized windowing value previously retained. The memory thus released can be reallocated for the remaining traffic according to their associated priority. With reference to FIG. 6, the main steps of an algorithm for updating the value of the window size for the transmission of a TCP stream c1 according to a preferred embodiment of the invention are presented. . This algorithm is implemented by a local network interconnection device 100. According to a first example in accordance with the invention, the stream C1 is one of the streams to be degraded which pass through the given QosDevice of FIG. Interconnection equipment is for example located on the path of transmission of cl during the implementation of the transmission method of c0 15 according to the aforementioned embodiment of the invention. According to a second example according to the invention, the flow cl is the aforementioned flow c0. The interconnection equipment comprises a UPnP service QosDevice, for example it is any of the interconnection equipment 140A to 140C of the network 100. Thus, as described with reference to FIG. 5, the equipment of Interconnection dialog with the QosManager 150. The presented algorithm indicates the actions performed by the interconnection equipment upon receiving, in a step 600, a SetupTrafficQos message relating to the TCP compliant cl stream. It is recalled that the MaxBurstSize field of the TSPEC structure of this SetupTrafficQos message contains an indication of the maxWD value of the negotiated TCP window size for cl on the local network 100. This algorithm makes it possible to check and enforce the application of this 30 QoS setpoint (traffic shaping principle) for Cl.

Preferably, this algorithm is implemented in the case where the client terminal of the cl transmission path is not compatible with the present invention (that is to say that it does not implement the algorithms (concerning the client terminal) described in connection with Figure 4). In fact, in this case, the actions requested by the QosManager 150 at the client terminal can not be implemented by the client terminal in order to configure the TCP flow with respect to the accepted QoS. In a step 601, the interconnection equipment executes the expected conventional actions of a QosDevice service such as the management of its internal resources for the admission of the cl stream, the storage of the QoS characteristics of the cl stream, etc. According to the present invention, in a step 602, the interconnection equipment checks whether the stream c1 is an already open stream (for an update) or a new stream.

In the case of a new stream, in a step 603, the interconnect device is waiting for a TCP SYN segment (or packet) for cl that characterizes the implementation of the TCP connection open protocol for cl. The information of the IP frame relating to the IP addresses or MAC addresses of the clients and servers, the port of the server, the protocol used, etc. can be compared with the information available in the characterization of the cl stream sent by the QosManager 150. through the SetupTrafficQos message. In a step 604, once the flow cl identified by the TCP SYN segment to the server 110, the value of the window size (hereinafter referenced WD) proposed by the client terminal is compared by the equipment 25 of interconnection with the maxWD value provided in the TSPEC specification structure of the accepted QoS for the cl stream. In the case where the proposed value (WD) is less than the accepted maxWD value, in a step 609, the algorithm is terminated. This value can, however, be communicated by the interconnect equipment to the QosManager 30 150 so that it takes into account the window size value 2908577 49 will be effective for the cl stream. The QosManager 150 will thus be able to renegotiate this window value with all the QosDevice interconnection equipment on the transmission path of the cl stream and thus release internal resources to the unnecessarily reserved QosDevices.

In the case where the proposed value (WD) is greater than the accepted maxWD value, in a step 605, the interconnection equipment implements a readjustment of the proposed value by inserting the maxWD value instead of the value the client terminal before forwarding the modified TCP SYN segment to the source of the cl stream and terminating the algorithm in step 609. As for step 408 of FIG. 4, the QosDevice service of the interconnection equipment may be particularized in order to transmit to the QosManager 150 additional information relating to the establishment of the TCP connection.

If the stream c1 is a stream already open (for an update), then a step 606 is implemented. The adaptation (or adjustment) steps 606 to 608 are identical to steps 603 to 605, except that: in step 606, the interconnect equipment waits for a TCP segment (or packet) ACK for and; in step 607, the value of the window size used during the advertised window is compared by the interconnect equipment with the maxWD value provided in the TSPEC specification structure. the allowed QoS for the cl stream (this is particularly useful when adjusting the value of the window size after opening the connection); in step 608, in case the window size used during the advertised window is greater than the accepted maxWD value, the interconnection equipment implements a readjustment of the value used by inserting the maxWD value.

At least one of the first and second possibilities according to the invention described in step 4 of FIG. 3 for supplying the new window size value for this stream C1 is then implemented. In the case where the window size used during the transmission of the stream 5 (advertised window) is less than the maxWD value accepted, the interconnection equipment can inform the QosManager 150 of this new value, so that the This takes into account the window size value that will be effective for the cl stream. The QosManager 150 will thus be able to renegotiate this window value with all the interconnection equipment of the QosDevice 10 type on the transmission path of the cl stream and thus release internal resources to the unnecessarily reserved QosDevices. Preferably, an additional test (not shown in this FIG. 6) is inserted between step 602 and step 606. This test consists in that if the value updated below referenced maxWD 'is identical to the maxWD value The original setpoint for the establishment of the stream C1, then the adaptation steps 606 to 608 are not implemented. The configuration of the TCP stream cl returns to the consideration of the initial window and the behavior of the stream TCP cl is regulated automatically. According to a preferred embodiment of the invention, as described in connection with FIG. 4, the DMP equipment integrates a QosDevice UPnP service in addition to UPnP AV MediaRenderer services. Steps 400 to 404 relate to the execution of a typical algorithm for a UPnP control station, while steps 406 and 408 reflect the behavior of the UPnP QosDevice service of the DMP equipment. As previously described, the execution of step 406 is conditioned upon receipt of the SetupTrafficQos message from the QosManager 150. Step 407 relates to the behavior of the AVTransport service of the UPnP AV protocol (i.e. say that the receipt of an Avt_Play () command message will allow the execution of step 407). In practice, since the control station is internal to the DMP, the command 30 Avt_Play () remains internal to the DMP.

According to a variant of the invention, the equipment DMP can be controlled by a remote control equipment equipment, such as the equipment 160: thus the control station 160 interacts directly with the AVTransport service of this equipment, it is that is, receipt of Avt_Play () requests causes step 407 to be executed. Note also that this equipment may be positioned on the data stream transit path: this is for example the the case of a PC station having the DMP functionality via application software, and which also has several network accesses making it an interconnection element as well as type 140 equipment. , the DMP equipment can also be considered as an intermediate device 140. In this case, the reception of a SetupTrafficQos message from the QosManager 150 will lead in step 406 to determine the position of the device. 15 of the current equipment in correspondence with the specified stream (new or update) by the aforementioned QoS message. This determination consists of finding out whether the current device is the stream recipient or only an intermediate device on the stream path: specific fields in the XML TrafficDescriptor structure (described in Appendix 2) of the 20 SetupTrafficQos message (such as the DestinationAddress field and DestinationPort) can easily be compared with the network characteristics of the equipment to determine whether the current equipment is the flow recipient or only an intermediate device on the flow path. In the case where the current equipment is indeed the recipient of the stream, it will proceed to the execution of step 407 as previously described in relation to FIG. flow but intermediate equipment on the path of the specified stream, it will proceed to the execution of step 601 as already described in relation with Figure 6.

APPENDIX 1 TCP (for "Transrnission Control Protocol" as defined by RFC 793) is an ARQ protocol that was created for the purpose of providing data transfers over the Internet according to strong speed and quality criteria. At least two mechanisms are used to handle the excess traffic arriving at a receiver: the first is to use receive buffers, and the second sets up a flow control. The TCP protocol reliably ensures the transfer of data, although it uses the IP protocol, which does not include any datagram delivery control. Indeed, the TCP protocol has a system of acknowledgment in English or ACK :) allowing the client and the server to ensure the good mutual reception of the data. When transmitting a segment, a sequence number (also called sequence number) is associated. Upon receipt of a data segment, the receiving machine will return a data segment whose ACK flag is 1 (to signal that it is an acknowledgment of receipt) accompanied by a number of acknowledgment of receipt equal to the previous order number. Since this communication process, which is done through a data transmission and an acknowledgment of receipt, is based on a serial number (or sequence number), the transmitting and receiving machines ( client and server) know the initial sequence number of the other machine (called Initial Sequence Number in English or ISN). The TCP connection is established in three stages: First, the client sends a segment with the SYN flag (or SYN message) to indicate that it is a synchronization segment. , with its initial sequence number (ISN = x). In a second step, the server receives the synchronization segment coming from the client, then sends it an acknowledgment, that is to say a segment whose ACK flag is at 1 and the SYN flag is at 1 including its It must also acknowledge the previous packet, which it does with an acknowledgment number that contains the client's initial order number, incremented by 1 (ack). = x + 1). Then, in a third step, the client transmits to the server a reception acknowledgment, that is to say a segment whose ACK flag is at 1, whose SYN flag is at 0, because it is no longer a question. a synchronization segment. Its serial number is incremented (seq = x + 1) and the acknowledgment number represents the initial sequence number of the server incremented by 1 (ack = y + 1). Once this phase called three-way handshake is completed, both applications are able to exchange the bytes that justify the establishment of the connection. Flow control manages the allocation of resources at the recipient level, such as memory and process. In general, in accordance with flow control, the destination sets a limit on the transmission rate implemented by all sources that send data to the destination. Sources and destinations coordinate data transfer through message exchange including requests and acknowledgments. Before the source starts sending packets, it sends a request to the destination for permission to begin transmitting. In response to this request, the destination sends a message including an identification of the number of packets that the source can transmit to the destination without further authorization. This number is commonly called "window size". Then, the source transmits the number of packets allowed to the destination and waits for the destination to check for their receipt. After the destination has successfully received a packet, it sends a message back to the source including an acknowledgment that the packet has been successfully received and, in some cases, allowing the source to send another packet. In this way, the number of packets on the network transiting from the source to the destination never exceeds the allowed window size.

2908577 54 We will distinguish between different names for TCP windows: - TCP window: the initial value validated during the establishment of the connection, which is the maximum value allowed during the entire duration of the connection; 5 cwnd or Congestion window: the current window value sent from the server in a TCP packet to the client; - acknowledge-window or advertised-window: the window value sent in a TCP ACK packet to the server, which indicates the memory usage in the client; 10 - sliding window: (for sliding window) window value internal to a server allowing him to know the number of data to be transmitted since the arrival of the last TCP acknowledgment segment. A large TCP window size encourages the broadcast. If the number of received data is greater than the window indicates, out-of-window data will be discarded. This loss leads to a large number of retransmissions and unnecessarily overloads the network and TCP. The use of a small window size breaks up the throughput by adding some extra delay to the "loop time", but limiting network overhead due to retransmissions. Opening a tiny window also reduces performance by increasing the weight of the headers relative to the data. Even with the implementation of these mechanisms, in a busy network, multiple sources simultaneously send streams in the network to more than one destination. If too many such streams converge to a single router in too short a lapse of time, then the limited buffered capacity of this router is not able to handle that volume of flow and this router will reject or destroy some of the packets. When such a situation occurs, the network is said to be congested. When such a situation occurs, the transfers in the network 30 slow down considerably and the network rate drops. Because some of the network resources are dedicated to implementing retransmissions, when the network is overloaded, there is a substantial risk of occurrence of congestion propagation and blocking of the entire network. The value of the TCP MSS field indicates the maximum amount of TCP data per IP datagram that the local system can accept. When sent, the IP datagram can be fragmented into multiple packets. Theoretically, this value can reach the value of 65495, however such an important value is never implemented. Typically, a terminal system uses the MTU interface (for "outgoing interface MTU") to which the value 40 is subtracted as its TCP MSS field value. For example, a TCP MSS field value for the Ethernet protocol is 1460 (1500 - 40 = 1460). The value of the TCP MSS field is populated in the packet that serves to establish the connection, which are the packets that contain the SYN signal. Each side sends its own TCP MSS field value. It is not required that each side use the same TCP MSS field value, but each side can not send more data than is allowed by the remote station. The value of the TCP MSS field is sent to the maximum segment size (for Maximum Segment Size or MSS) of the TCP header option. It should be noted that the default value of the buffer size of the connection interface differs greatly depending on the implementation. Older Berkeley-derived implementations impose default values of receive and send TCP buffers at 4KB, while newer systems implement larger values (up to 64KB). For example, in WINDOWS XP (registered trademark), the current value of the receive window size automatically adjusts according to the even increments of the maximum segment size (MSS) negotiated during the establishment of the TCP connection.

2908577 56 APPENDIX 2 <TrafficDescriptor> <td: TrafficHandle> flowl </ td: TrafficHandle> 5 <td: Trafficld> <td: SourceAddress> <td: Ipv4> 192.168.1.50 </ td: Ipv4> </ td: SourceAddress> <td: SourcePort> 23 </ td: SourcePort> 10 <td: DestinationAddress> <td: Ipv4> 192.168.1.50 </ td: Ipv4> </ td: DestinationAddress> <td: DestinationPort> 23 </ td: DestinationPort> <td: IpProtocol> 6 </ td: IpProtocol> 15 </ td: Trafficld> <td: AvailableOrderedTspecList> <td: Tspec> <td: TspecIndex> 300 </ td: TspecIndex> <td: AvTransportUri> "http: / /192.168.1.51/ 20 videol.mpeg "</ td: AvTransportUri> <td: TrafficClass> AV </ td: TrafficClass> <td: MeanDatarate> 50 </ td: MeanDatarate> </ td: Tspec> <td: Tspec > 25 <td: Tspeclndex> 2 </ td: Tspeclndex> <td: AvTransportUri> "http://192.168.1.51/soundl.mp3" </ td: AvTransportUri> <td: TrafficClass> Audio </ td: TrafficClass> <td: MeanDatarate> 9 </ td: MeanDatarate> 30 </ td: Tspec> </ td: Available0rderedTspecList> <(f rafficDescriptor> 5 10 2908577 57 APPENDIX 3 <td: Tspec> <td: Tspeclndex> 300 </ td : Tspeclndex> <td: AvTransportUri> "http: //192.168. 1.51 / videol.mpeg "</ td: AvTransportUri> <td: TrafficClass> AV </ td: TrafficClass> <td: MeanDatarate> 50 </ td: MeanDatarate> <td: MaxBurstSize> 4380 </ td: MaxBurstSize> </ td: Tspec> 15

Claims (28)

  A resource management method for transmitting in a communication network (100) a first data content between a first source device (110) and a first receiving device (120A, 120B) on a first transmission path comprising at least one first intermediate device (140A, 140B, 140C), characterized in that a manager device (150) performs the following steps: determining a set of acceptable window size values for transmission of the first content; determining a window size value, said first accepted value, from the set of acceptable acceptable window size values, said first accepted value being the maximum window value accepted by at least said at least one first intermediate device for the transmission of the first content; sending, to the first receiver device, information representative of said first accepted value in order to initialize transmission of the first content between the first source device and the first receiver device according to a window size equal to said first accepted value.   2. Resource management method according to claim 1, characterized in that the step of determining the first accepted value also comprises the following steps: selecting an acceptable window size value from the set of values of acceptable window size, said first selected current value; determining if the first current selected value is accepted by said at least one first intermediate device; in the case of a negative determination, reiterating the selection and determination steps with a first selected value below the first selected current value.   3. Resource management method according to claim 2, characterized in that the step of determining if the first current selected value is accepted by said at least one first intermediate device comprises the following step: - sending audit at least a first intermediate device of a resource allocation request corresponding to the first current selected value, and in that a window size value is considered to be accepted by said at least one first intermediate device when the manager device receives said at least one first intermediate device has a positive resource allocation ratio corresponding to the first selected current value.   4. Resource management method according to claim 3, characterized in that, prior to the reiteration step, it comprises the following steps: - determination of one or more devices, said device (s) accepting, among the or the first intermediate device (s), having accepted the first current selected value; sending to said accepting device (s) a resource release request corresponding to the first current selected value.   A resource management method according to any one of claims 1 to 4, characterized in that, in the case where no first selected value is accepted in the step of determining a first accepted value, it also comprises the following steps: selecting at least a second data content, the second content being transmitted between a second source device and a second receiving device on a second transmission path comprising at least a second intermediate device (140A, 140B, 140C), at least one of said second device (s) intermediate (s) being also one or said first device (s) intermediate (s); determining an acceptable window size value, said second acceptable value, for transmitting the second content; Sending, to at least said at least one second intermediate device, information representative of said second acceptable value in order to update the transmission of the second content according to a window size equal to said second acceptable value. 5   6. resource management method according to any one of claims 1 to 5, characterized in that a window size value is said to be acceptable for the transmission of a content if it verifies at least one of the criteria belonging to the group comprising: the window size value is greater than a maximum packet size value of the content; the window size value is greater than a predefined minimum value satisfying n * MSS, where n is a coefficient dependent on the priority of the content and MSS is a maximum packet size value of the content; The window size value is greater than a minimum window size for transmission of less priority content; the window size value is less than a max_bandwidth * RTT product on the content transmission path, where max_bandwidth is the maximum theoretical bandwidth on the content transmission path and RTT is an averaged value of the travel time of the content transmission path; path of transmission of the content.   A resource management method for transmitting in a communication network (100) a data content between a source device (110) and a receiving device (120A, 120B) on a transmission path comprising at least one intermediate device (140A, 140B, 140C), characterized in that one or said intermediate devices (140A, 140B, 140C), said device involved, performs the following steps: receiving a message comprising a window size value accepted by at least said at least one intermediate device for transmitting said content; Determining the position on the transmission path of said device involved; - In the case where the device involved is the receiving device, sending to the source device of a message, said first initialization message, 5 initialization of the transmission of the content, said first initialization message comprising the accepted value.   8. Resource management method according to claim 7, characterized in that, in the case where the device involved is not the receiving device, the method comprises the following steps: receiving a message, said second message initialization, initialization of the transmission of the content, said second initialization message comprising at least one value indicating a level of resources available on the receiving device for transmitting the content, said value retained; Determining whether the value selected is greater than the accepted value; if the value selected is greater than the accepted value, modifying said second initialization message, replacing the value retained by the accepted value; sending said second initialization message to the source device. 20   9. Resource management method according to claim 8, characterized in that, in the case where the device involved is not the receiving device, the method comprises the following steps: - reception of a message, said message of acknowledgment of acknowledgment of the initialization of the transmission of the content, said acknowledgment message comprising at least one value indicating a level of resources available on the server for the transmission of the content, said retained value; -determination if the value chosen is greater than the accepted value; if the value selected is greater than the accepted value, modifying said acknowledgment message, replacing the value retained by the accepted value; sending said acknowledgment message to the receiver device.   10. Transmission method according to one of claims 8 and 9, characterized in that, if the value selected is not greater than the accepted value, it further comprises the following step: sending to a device manager in accordance with a centralized signaling protocol, a message including the retained value, to allow an update of an accepted window size value for the data content. 10   11. resource management method according to any one of claims 7 to 10, characterized in that it further comprises the following steps: receiving at least one packet of the content; determining from said at least one received packet of a minimum window size value for transmitting the content, said lower value; - sending to a management device, the lower value, to allow an update of a set of acceptable window size values for the transmission of content. 20   12. Resource management method according to claim 11, characterized in that the lower value corresponds to a maximum packet size value of the content.   A resource management method according to any one of claims 7 to 12, characterized in that a window size value is said to be acceptable for transmission of content if it verifies at least one of the criteria belonging to the group comprising: the window size value is greater than a maximum packet size value of the content; the window size value is greater than a predefined minimum value checking n * MSS, where n is a coefficient dependent on the priority of the content and MSS is a maximum packet size value of the content; the window size value is greater than a minimum window size for transmission of less priority content; 5 - the window size value is less than a product max_bandwidth * RTT on the content transmission path, where max_bandwidth is the maximum theoretical bandwidth on the content transmission path and RTT is an averaged value of the travel time of the content. path of transmission of the content. 10   14. Computer program product, downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, characterized in that it comprises program code instructions for the implementation resource management method according to at least one of claims 1 to 6 and / or the resource management method according to at least one of claims 7 to 13.   15. Storage medium, possibly totally or partially removable, readable by a computer, storing a set of instructions executable by said computer to implement the resource management method according to at least one of claims 1 to 6 and / or the resource management method according to at least one of claims 7 to 13.   A manager device comprising resource management means for transmitting in a communication network (100) a first data content between a first source device (110) and a first receiver device (120A, 120B) on a first transmission path 25 comprising at least a first intermediate device (140A, 140B, 140C), characterized in that the management means comprise: means for determining a set of acceptable window size values for the transmission of the first content ; means for determining a window size value, said first accepted value, from the set of acceptable window size values, said first accepted value being the maximum window value accepted by at least said minus a first intermediate device for transmitting the first content; means for sending, to the first receiver device, information representative of said first accepted value in order to initialize transmission of the first content between the first source device and the first receiver device according to a window size equal to said first accepted value.   Managerial device according to claim 16, characterized in that the means for determining the first accepted value comprise: means for selecting an acceptable window size value from the set of acceptable window size values, said first selected current value; determining means if the first current selected value is accepted by said at least one first intermediate device; activation means, in the case of a negative determination, of said selection means and said determination means with a first selected value below the first selected current value. 20   18. Management device according to claim 17, characterized in that the means for determining whether the first current selected value is accepted by said at least one first intermediate device comprise: means for sending to said at least one first intermediate device; a resource allocation request corresponding to the first current selected value, and in that a window size value is considered to be accepted by said at least one first intermediate device when the management device receives from said at least one first device intermediate a positive resource allocation report corresponding to the first selected value: 30 current. 2908577 65   19. Management device according to claim 18, characterized in that the management means comprise in operation: - means for determining one or more devices, said device (s) accepting, among the first (s) device (s) ( s) intermediate (s), having accepted the first current selected value; means for sending to said device (s) accepting a request for the release of resources corresponding to the first current selected value.   20. Management device according to any one of claims 16 to 19, characterized in that the management means also comprise: means for selecting at least a second data content, the second content being transmitted between a second source device and a second receiver device on a second transmission path comprising at least a second intermediate device (140A, 140B, 140C), at least one of said second device (s) intermediate (s) being also one or more of said first intermediate device (s); means for determining an acceptable window size value, said second acceptable value, for transmitting the second content; Means for sending, to at least said at least one second intermediate device, information representative of said second acceptable value in order to update the transmission of the second content according to a window size equal to said second acceptable value; .   21. Managerial device according to any one of claims 16 to 20, characterized in that a window size value is said to be acceptable for the transmission of a content if it verifies at least one of the criteria belonging to the group comprising: the window size value is greater than a maximum packet size value of the content; The window size value is greater than a predefined minimum value checking n * MSS, where n is a coefficient dependent on the priority of the content and MSS is a maximum packet size value of the content; the window size value is greater than a minimum window size for the transmission of less priority content; the window size value is less than a product max_bandwidth * RTT on the content transmission path, where max_bandwidth is the maximum theoretical bandwidth on the content transmission path and RTT is an averaged value of the path time of the content. path of transmission of the content.   A transmission device comprising resource management means for transmitting in a communication network (100) a data content between a source device (110) and a receiving device (120A, 120B) on a transmission path comprising at least one intermediate device (140A, 140B, 140C), said transmission device being one or more of said intermediate devices (140A, 140B, 140C), characterized in that the management means comprise: reception means of a message comprising a window size value accepted by at least said at least one intermediate device for transmitting said content; means for determining the position, on the transmission path, of said transmission device; means for sending to the source device of a message, said first initialization message, of initialization of the transmission of the content, said first initialization message comprising the accepted value, said sending means being activated if the transmission device is the receiver device.   23. Transmission device according to claim 22, characterized in that, the transmission device being distinct from the receiver device, the management means comprise: means for receiving a message, said second initialization message initializing the transmission of the content, said second initialization message comprising at least one value indicating a level of resources available on the receiving device for the transmission of the content, said retained value; means for determining whether the value selected is greater than the accepted value; means for modifying said second initialization message, replacing the value retained by the accepted value, said modifying means being activated if the value retained is greater than the accepted value; means for sending said second initialization message to the source device.   24. Transmission device according to claim 23, characterized in that, the transmission device being distinct from the receiver device, the management means comprise: means for receiving a message, called an acknowledgment message, acknowledgment of the initialization of the transmission of the content, said acknowledgment message comprising at least one value indicating a level of resources available on the server for the transmission of the content, said retained value; means for determining whether the value selected is greater than the accepted value; means for modifying said acknowledgment message, replacing the value retained by the accepted value, said modifying means being activated if the value retained is greater than the accepted value; means for sending said acknowledgment message to the receiver device.   25. Transmission device according to one of claims 23 and 24, characterized in that the management means further comprise: means for sending to a management device according to a centralized signaling protocol, a message including the retained value, to allow an update of an accepted window size value for the data content, said sending means being activated if the retained value is not greater than the accepted value. 5   26. Transmission device according to any one of claims 22 to 25, characterized in that the management means further comprise: means for receiving at least one packet of the content; means for determining from said at least one received packet a minimum value of window size for the transmission of the content, called a lower value; means for sending to a management device, of the lower value, in order to allow updating of a set of acceptable window size values for the transmission of the content.   Transmission device according to claim 26, characterized in that the lower value corresponds to a maximum packet size value of the content.   28. Transmission device according to any one of claims 22 to 27, characterized in that a window size value is said to be acceptable for the transmission of a content if it verifies at least one of the criteria belonging to the group comprising : - the window size value is greater than a maximum packet size value of the content; the window size value is greater than a predefined minimum value satisfying n * MSS, where n is a priority coefficient: 25 of the content and MSS is a maximum packet size value of the content; the window size value is greater than a minimum window size for transmission of less priority content; the window size value is less than a product max_bandwidth * RTT on the content transmission path, where max_bandwidth is the theoretical maximum bandwidth on the content transmission path and RT'T is an averaged value of the content transmission path. travel time of the content transmission path.