Internet Engineering Task Force Borje Ohlman INTERNET-DRAFT Ericsson Expires: September 1998 10 March 1998 Receiver control in Differentiated services Abstract This draft addresses the issue of receiver control for the specific case where the receiver needs to control incoming traffic on its own access link. This is of particular importance for low bandwidth links. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Introduction In Differentiated Services the TOS bits are set at the sender side of the network. At receivers access link this setting might not reflect how the receiver wants the incoming traffic prioritized. This draft discusses how this problem could be solved by applying a different semantics for the TOS bits at the last hop router compared to what is applied through the rest of the network. As a consequence of this it should be noted that per hop behaviours (PHB) should not be Ohlman Expires: September 1998 [Page 1] =0C INTERNET-DRAFT draft-ohlman-receiver-ctrl-diff-00.txt 10 March 1998 overspecified as they might need to be radically different on a wireless hop than on a SONET hop. 2. Types of receiver control The concept of receiver control can be applied to (at least) two different contexts. One is when the receiver is allowed to control which priority should be set by the sender (this can be of interest for a user who is eager to get the result from a http request delivered promptly). Another type is when the receiver need to control the priority of the packets that comes from the network onto his/her access link. Two reasons why this is important. One is that it provides protection from certain types of denial of service attacks. The other is that this is important on low bandwidth access links, in particular for cellular IP hosts. This proposal does not try to address the first type of receiver control. We simply note that this problem can initially be solved at the session or application layers. It still remains to be shown that a mechanism is needed at the network layer. This proposal suggests a method for giving the receiver control over his/her access link. 3. Motivation for access link receiver control The problem with low bandwidth access links are not going away within the foreseeable future. In addition to an expected continued use of dial-up modem connections over POTS we expect to see large number of mobile phones becoming IP hosts. Example: A user is having an IP-phone conversation with a person. This person then asks our user to look at a web page. The web page our user requests comes from a commercial web server which prides itself of always giving prompt responses, this includes sending all traffic as high priority. If the IP-phone conversation is only using best effort it might be severely degrade by the http-download, this is most likely not what our user would like. In the current diff-serv discussions the focus seems to be on having edge devices rather than users/end-systems setting the TOS-bits. Assuming this setting is done according to service level agreements with the senders ISPs, the receiver has no way of influencing the way the traffic is prioritized. Ohlman Expires: September 1998 [Page 2] =0C INTERNET-DRAFT draft-ohlman-receiver-ctrl-diff-00.txt 10 March 1998 The low priority of the IP-phone traffic is not a problem through a lightly loaded backbone network. It is not until it is merged with the web download on the low-bandwidth access link to the receivers laptop a significant delay occurs. If the receiver could control how the traffic is prioritized over the narrow access link this could easily be solved. 4. Suggested solution To give the receiver control over which flows it values most we suggest that the semantics of the priority bits is changed across the receivers access link, compared to within the network. Instead of defining the priority over the access link they will be regarded as a request. This will mean that the access node will not grant priority according to TOS bits unless they are in agreement with the receivers wishes. The receivers preferences can either be expressed via static configuration in a user profile or the user can be prompted (via a separate application) for each new incoming flow. This gives the user the power to control the incoming traffic on his/her access link. 5. Denial of service attacks If someone is trying to flood your access link with high priority packets, the above suggested mechanism can help the user to make sure those packets are dropped at the last hop router, thus protecting the preferred traffic on a low bandwidth link. 6. Considerations In a lot of cases it is expected that source address will provide enough information for meaningful flow identification (which allows this mechanism to work also with end-to-end encrypted traffic). The amount of traffic dropped in an overload situation is the same with or without this mechanism, the difference is that this gives the receiver a better chance of influencing which traffic is dropped. 7. Conclusion This draft points out that there are variants on the concept of receiver control. This should be reflected in the diff-serv framework document. It should also be clarified which of these aspects the current diff-serv work intends to address. To make it possible for the receiver to control its own access link it is important that the diff-serv standard allows for the last hop Ohlman Expires: September 1998 [Page 3] =0C INTERNET-DRAFT draft-ohlman-receiver-ctrl-diff-00.txt 10 March 1998 router to priorities traffic in accordance with the receivers requests even if this is in contradiction with the TOS-bits settings. To achieve this the TOS bits should only be regarded as requests at the last hop router. References [1] D. Clark and J. Wroclawski, "An Approach to Service Allocation in the Internet", Internet Draft , July 1997. [2] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", Internet Draft , November 1997. [3] K. Nichols and S Blake, "Differentiated Services Operational Model and Definitions", Internet Draft , February 1998. Author's Address Borje Ohlman Ericsson Dialoggatan 1 (Kungens Kurva) S-126 25 Stockholm Sweden Phone: +46-8-719 3187 Fax. +46-8-719 6677 E-mail: Borje.Ohlman@ericsson.com Ohlman Expires: September 1998 [Page 4]