idnits 2.17.1 draft-ohlman-receiver-ctrl-diff-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 369 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (30 September 1998) is 9340 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 303, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 307, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 311, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Borje Ohlman 2 INTERNET-DRAFT Ericsson 3 Expires: March 1999 Petri Koskelainen 4 Nokia 6 30 September 1998 8 Receiver control in Differentiated services 10 12 Abstract 14 This draft addresses the issue of receiver control for the 15 specific case where the receiver needs to control incoming traffic 16 on its own access link. This is of particular importance for low 17 bandwidth links. 19 Status of this Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its 23 areas, and its working groups. Note that other groups may also 24 distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 To learn the current status of any Internet-Draft, please check 33 the "1id-abstracts.txt" listing contained in the Internet-Drafts 34 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 35 (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 36 Coast), or ftp.isi.edu (US West Coast). 38 1. Introduction 40 In Differentiated Services the TOS bits are set at the sender side of 41 the network. At receivers access link this setting might not reflect 42 how the receiver wants the incoming traffic prioritized. This draft 43 discusses how this problem could be solved by applying a different 44 semantics for the TOS bits at the last hop router compared to what is 45 applied through the rest of the network. It is important to recognize 46 that the receiver (the owner) of access link must always be capable 47 of fully controlling the the usage of that access link. 49 2. Types of receiver control 51 The concept of receiver control can be applied to (at least) two 52 different contexts. One is when the receiver is allowed to control 53 which priority should be set by the sender (this can be of interest 54 for a user who is eager to get the result from a http request 55 delivered promptly). Another type is when the receiver need to 56 control the priority of the packets that comes from the network onto 57 his/her access link. Two reasons exists why this is important. One is 58 that it provides protection from certain types of denial of service 59 attacks. The other is that this is important on low bandwidth access 60 links, in particular for cellular IP hosts. 62 This proposal does not try to address the first type of receiver 63 control. We simply note that this problem can initially be solved at 64 the session or application layers. It still remains to be shown that 65 a mechanism is needed at the network layer. 67 This proposal suggests a method for giving the receiver control over 68 his/her access link. Note that there exists two cases of this access 69 link issue. First there is last-hop access link issue, and secondly 70 there is organization's access link issue. 72 3. Motivation for access link receiver control 74 The problem with low bandwidth access links are not going away within 75 the foreseeable future. In addition to an expected continued use of 76 dial-up modem connections over POTS we expect to see large number of 77 mobile phones becoming IP hosts. 79 Example 1: Receiver control in an organization's access link. 81 This problem arises e.g. between a company LAN and an ISP. 82 For example, a company may have a 64 Kbit/s incoming link 83 from an ISP. If a company worker is surfing the web and clicks 84 on an advertisement video button (e.g. about new car model) 85 which consumes ~100 Kbit/s (marked with highest possible DS value). 86 One such advertisement video will utilize whole access link 87 capacity thus preventing all other activities in that link. 88 E.g. if the company CEO wants to download something urgently or to 89 use an IP phone application he/she is unable to do so. 91 Example 2: Receiver control in low bitrate last-hop link. 93 A user is having an IP-phone conversation with a person. This person 94 then asks our user to look at a web page. The web page our user 95 requests comes from a commercial web server which prides itself of 96 always giving prompt responses, this includes sending all traffic as 97 high priority. 98 If the IP-phone conversation is only using best effort it might be 99 severely degrade by the http-download, this is most likely not what 100 our user would like. 102 In the current diff-serv discussions the focus seems to be on having 103 edge devices rather than users/end-systems setting the TOS-bits. 104 Assuming this setting is done according to service level agreements 105 with the senders ISPs, the receiver has no way of influencing the way 106 the traffic is prioritized. 108 The low priority of the IP-phone traffic is not a problem through a 109 lightly loaded backbone network. It is not until it is merged with 110 the web download on the low-bandwidth access link to the receivers 111 laptop a significant delay occurs. If the receiver could control how 112 the traffic is prioritized over the narrow access link this could 113 easily be solved. 115 These two similar kind of problems exists at 116 the edge of differentiated services Internet. 118 They can be solved by receiver control, depending 119 on the needed flexibility it can be achieved in 120 two ways: 122 1) Static configuration (receivers have beforehand 123 defined some policies, e.g. packets from company.com 124 are always the most important packets) 126 2) Dynamic configuration (signalling) 128 In many situations static configuration will be too 129 limited. Then some kind of signalling is needed. 130 Although DiffServ is based on "no signalling" approach, 131 this signaling should not affect the diff serv world 132 since it is applied purely in the end user network 133 (access link or end users low bitrate last-hop link). 134 Basically it is no different than using RSVP at the edges. 136 4. Suggested solution 138 To give the receiver control over which flows it values most we 139 suggest that the semantics of the priority bits is changed across the 140 receivers access link, compared to within the network. Instead of 141 defining the priority over the access link they will be regarded as a 142 request. This will mean that the access node will not grant priority 143 according to TOS bits unless they are in agreement with the receivers 144 wishes. The receivers preferences can either be expressed via static 145 configuration in a user profile or the user can be prompted for each 146 new incoming flow. 148 This gives the user the power to control the incoming traffic on 149 his/her access link. 151 The idea is that DiffServ marked flows are treated like best-effort 152 flows in access link unless otherwise ordered by the receiver. 154 The receiver acknowledges the request (DS-marked best-effort packet 155 itself is a requests) to next-hop router whenever it wants to accept 156 the DiffServ flow. 158 Otherwise the flow continues as a Best-Effort flow. The receiver may 159 send the Ack beforehand (e.g. when starting the application level 160 signalling like SIP, H.323, WWW clicking etc) or when it gets the 161 first DS-marked packet (which cames as a BE packet). 163 ACK messages should be forwarded upstream until they reach a router 164 that has not been configured as a "last hop router", i.e. it does 165 not understand the ACK message. 167 A router may be configured to forward ACK messages upstream (e.g. 168 last-hop router may forward ACK to corporate access router). 169 Receiver must send the ACK always to its closest router. These 170 forwarding issues can be defined in service level agreements (SLAs). 171 Router can be defined to accept and/or forward ACK messages. 172 Router which is not allowed to accept ACK messages must silently 173 discard those. 175 Example: 177 Access network ISP 179 Recv.------R1----------------ISP-R1---------Internet------Sender 181 1. Sender starts sending packets with highest possible DiffServ values 182 2. Packets travel through DS-capable network 183 3. Packets reach ISP-R1 which forwards packets as best-effort to access 184 link. 185 4. Receiver gets first packets and it sends ACK to R1. Now R1 honours 186 DS-values for that flow. 187 5. R1 sends ACK to ISP-R1 (which is propably the actual bottleneck). 188 Now ISP-R1 accepts incoming DS-packets for that flow (instead of 189 treating those as BE packets). 190 6. Packets from sender to destination are handled everywhere as they 191 should be handled. Receiver makes periodically ACK refresments. 193 Following chapter defines the packet format for this simple dynamic 194 DiffServ Ack Protocol (DAP). 196 5. Packet Format 198 This ACK packet is sent to special UDP port (TBD). There is not any 199 negotiation involved but the refreshment timer can be defined by the 200 receiver. The packet format is as follows: 202 Fixed format: 204 0 1 2 3 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |V=1| IPv | Res. | Protocol | Aut. | Timer | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 V: 2 bits. Version number. Current version is 1. 211 IPv: 4 bits. IP version number. Currently IPv4 and IPv6 are defined. 212 Reserved: 4 bits . Reserved for future use. 213 Protocol: 8 bits. The protocol number (usually UDP). 214 Aut: 4 bits. Authentication is in use. Currently only Aut=1 is defined 215 (means RSVP User Identity). 216 Timer: 10 bits. This contain the value in seconds for the ACK refresh 217 period. If router does not get any ACK for some flow in 218 (timer*2) seconds then DS-enabling state is released. 219 Maximum refresment interval is 1024 seconds (about 17 minutes). 220 If timer=0 then refresments are not used at all. 222 Depending on the IP version number, following additional header 223 is included. Wildcarding is allowed (using zeros). 225 Case IPv4: 227 0 1 2 3 228 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | IPv4 Source IP Address | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | IPv4 Destination Address + 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Src Port | Dest Port | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Case IPv6: 239 0 1 2 3 240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 | IPv6 Source Address | 244 | | 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | | 248 | IPv6 Dest. Address | 249 | | 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Src Port | Dest Port | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Reserved | Flow Label | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 It is also possible to have authentication header included. In that 258 case Aut=1 and the rules for RSVP user identity [4] are followed. 260 +-------------+-------------+-------------+-------------+ 261 | Length | P-Type = AUTH_DATA | 262 +-------------+-------------+-------------+-------------+ 263 | AuthMethod | 0 (Reserved) | 264 +-------------+-------------+-------------+-------------+ 265 // Authentication Attribute List // 266 | | 267 +-------------------------------------------------------+ 269 6. Denial of service attacks 271 If someone is trying to flood your access link with high priority 272 packets (e.g. aggressive marketers), the above suggested mechanism 273 can help the user to make sure those packets are dropped at the last 274 hop router (or in corporate access link router), thus protecting the 275 preferred traffic on a low bandwidth link. 277 7. Considerations 279 In a lot of cases it is expected that source address will provide 280 enough information for meaningful flow identification (which allows 281 this mechanism to work also with end-to-end encrypted traffic). 283 The amount of traffic dropped in an overload situation is the same 284 with or without this mechanism, the difference is that this gives the 285 receiver a better chance of influencing which traffic is dropped. 287 8. Conclusion 289 This draft points out that there are variants on the concept of 290 receiver control. This should be reflected in the diff-serv framework 291 document. It should also be clarified which of these aspects the 292 current diff-serv work intends to address. 294 To make it possible for the receiver to control its own access link 295 it is important that the diff-serv standard allows for the last hop 296 router to priorities traffic in accordance with the receivers 297 requests even if this is in contradiction with the TOS-bits settings. 298 To achieve this the TOS bits should only be regarded as requests at 299 the last hop router. 301 References 303 [1] D. Clark and J. Wroclawski, "An Approach to Service Allocation in 304 the Internet", Internet Draft , July 1997. 307 [2] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated 308 Services Architecture for the Internet", Internet Draft , November 1997. 311 [3] K. Nichols and S Blake, "Differentiated Services Operational 312 Model and Definitions", Internet Draft , February 1998. 315 [4] S. Yadav, R. Pabbati, P. Ford and S. Herzog, "User Identity 316 Representation for RSVP", Internet Draft , March 1998. 319 Author's Address 321 Borje Ohlman 322 Ericsson 323 Varuv�gen 9 (�lvsj�) 324 S-126 25 Stockholm 325 Sweden 327 Phone: +46-8-719 3187 328 Fax. +46-8-719 6677 329 E-mail: Borje.Ohlman@ericsson.com 331 Petri Koskelainen 332 Nokia Research Center 333 P.O. 100 334 FIN-33721 Tampere 335 Finland 337 E-mail: petri.koskelainen@research.nokia.com