Internet Engineering Task Force                             Borje Ohlman
INTERNET-DRAFT                                                  Ericsson
Expires: September 1998
                                                           10 March 1998


              Receiver control in Differentiated services

                <draft-ohlman-receiver-ctrl-diff-00.txt>

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).


.  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.

.  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.

.  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.

.  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.

.  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.

.  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.

.  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

   [] D. Clark and J. Wroclawski, "An Approach to Service Allocation in
       the Internet", Internet Draft <draft-clark-diff-svc-alloc-
       00.txt>, July 1997.

   [] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated
       Services Architecture for the Internet", Internet Draft <draft-
       nichols-diff-svc-arch- 00.txt>, November 1997.

   [] K. Nichols and S Blake, "Differentiated Services Operational
       Model and Definitions", Internet Draft <draft-nichols-dsopdef-
       00.txt>, 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]