One document matched: draft-sun-alto-notification-02.txt
Differences from draft-sun-alto-notification-01.txt
< ALTO > A.Wang
K.Li
Internet Draft K.Zhou
Intended status: Standards Track X.Sun
Internet Draft China Telecom
Expires: November 2010 May 20, 2010
Server notification mechanism for ALTO optimization
draft-sun-alto-notification-02.txt
Abstract
The cooperation between Internet application and network enhances not
only the efficiency of network transportation but also the experiences
of end users. To design the information exchanging protocol and
architecture that facilitate such cooperation is the objective of
Application-Layer Traffic Optimization (ALTO) working group.
Currently, ALTO protocol adopts an efficient query/response message
based on the prevalent http protocol. However, such protocol cannot
support rapid dispatch of ALTO information. Noted that many scenarios
require the updated network information to be dispatched to clients as
soon as possible, such as when part of the network is congested, when a
new policy is to be deployed urgently, or when unexpected network
maintenance is required. To tackle such problem, this draft proposed a
server notification extension to the original query/response mechanism.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
<A.Wang> Expires November 20, 2010 [Page 1]
Internet-Draft < Notification > May 2010
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 20, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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.
<A.Wang> Expires November 20, 2010 [Page 2]
Internet-Draft < Notification > May 2010
Table of Contents
1. Introduction ................................................ 3
2. Server Notification Mechanism ............................... 4
2.1. Overview of Server Notification Mechanism ............... 4
2.2. Scope of server notification mechanism .................. 5
2.3. Registration Methods of ALTO Clients .................... 6
2.4. Server Notification Mode ................................ 6
2.5. Implementation Consideration ............................ 7
3. Server Notification Messaging ............................. 7
3.1. The processing ......................................... 7
3.2. Message format ......................................... 8
4. Discussion .................................................. 9
4.1. tracker-less p2p situation ............................ 9
5. Security Considerations ................................. 10
6. IANA Considerations ........................................ 10
7. Acknowledgment ............................................. 10
8. References ................................................. 10
Author's Addresses ............................................ 11
1. Introduction
Internet application, especially p2p applications, can benefit from
knowing the underlying network topology information via the ALTO
protocol [I-D.ietf-alto-protocol]. The ALTO clients query the ALTO
server periodically to get the updated ALTO information. Such method
is simple and effective given that the ALTO information is seldom
changes.
However, there are some situations that the ALTO information changes
occasionally. For example, due to network congestion, traffic load
<A.Wang> Expires November 20, 2010 [Page 3]
Internet-Draft < Notification > May 2010
fluctuation, or management requirement, an ISP may change its
traffic optimization policy. This generally results in an update of
ALTO information.
With simple query/response method, a possible way to tackle such
situations is to shorten the query interval. But this may flood the
ALTO sever with a large amount of query messages. A shorter query
interval also increases the traffic generated by ALTO. That is, a
shorter query interval may exacerbate the network congestion in some
sense. Moreover, as most of the ALTO information seldom changes, the
information carried is not proportional to the amount of traffic
generated.
Another method is to modify the ALTO protocol. If the ALTO server
can notify the ALTO clients proactively the change of ALTO
information, the traffic formed by the ALTO clients will be
optimized timely. The ALTO server and the ALTO clients will be
relieved from the unnecessary query/response messages.
This draft describes the ALTO server notification mechanism which
can be incorporated into the current ALTO protocol, its main
applicable scope and the detail process. Such mechanism can
certainly increase the efficiency of ALTO protocol.
2. Server Notification Mechanism
2.1. Overview of Server Notification Mechanism
Within currently ALTO protocol, the ALTO clients can only get the
ALTO information via the query/response mechanism. The query period
<A.Wang> Expires November 20, 2010 [Page 4]
Internet-Draft < Notification > May 2010
is one key parameter that needs to be considered. If this value is
set very short, ALTO messages may burden the underlying network; if
it is set very long, the ALTO clients may not able to get the
updated ALTO information in time.
Given that the ISP may change their policy occasionally, enable the
ALTO server to notify the clients of updated ALTO information as
soon as possible is reasonable. When an ALTO server determines that
a major change has occurred and the clients should know the change,
the server broadcast a notification message to its clients. On
receiving the notification message, the ALTO clients can send a
query message to the server and fetch the ALTO information that they
interested in.
2.2. Scope of server notification mechanism
The ALTO protocol is aimed to p2p and non-p2p internet applications
that can utilize the network information to optimize their
performances.
From the statistics of China Telecom's IP traffic reports, the
tracked-based p2p applications and other non-p2p, distributed web
services (such as CDN-based web services) produce exceed 80% of the
internet traffic. The developers of these applications are also more
easily cooperative with ISP to increase the traffic transport
efficiency.
This draft will focus mainly on these applications that creating
large amounts of flow in internet.
<A.Wang> Expires November 20, 2010 [Page 5]
Internet-Draft < Notification > May 2010
2.3. Registration Methods of ALTO Clients
In order to notify the ALTO clients actively, the ALTO server needs
to know the IP addresses and the listening ports of an ALTO client
in advance. Such information can be gotten via the contracts with
ISP or by other out-of-band methods.
The ALTO Server will keep one table (referred as "candidate table"
in following) that records the IP addresses/ports information of
these ALTO clients (referred as "registered ALTO clients" in
following). It will be kept permanently in ALTO sever unless changed
or removed by the ISP.
2.4. Server Notification Mode
The server notification mechanism can be designed in a general mode
or in a specific mode.
In the general mode, if there is any change of network condition,
which leads to the information change of network map, cost map or
other information provided by ALTO server, the server sends notify
message to all the registered ALTO clients. These registered ALTO
clients then send the query messages to ALTO server, together with
their own map filter, to get the interested ALTO information
respectively.
With the specific mode, a specific notification message is send to
all registered ALTO clients. This specific message points out which
part of the ALTO information has been changed. The interested ALTO
clients, not all registered ALTO clients, then send query message to
<A.Wang> Expires November 20, 2010 [Page 6]
Internet-Draft < Notification > May 2010
ALTO server, together with the map filter, to get the changed ALTO
information.
2.5. Implementation Consideration
The notification service can lessen the burden of the ALTO server.
That is, it is acceptable to incorporate such service in the ALTO
server, as an independent module. However, notification service can
also be provided by a dedicated notification server, if the
notification service becomes a burden to the original ALTO server.
3. Server Notification Messaging
This section specifies notification processing and message format.
3.1. The processing
Once an ALTO server determines that a notification to its clients is
required the ALTO server will build the notification message and
send it to the ALTO clients. Upon receiving the notification, a
client checks whether the notification is a general notification or
a specific notification. The local ALTO information updating logic
of the client determines the next processing step. If the client
receives a general notification, and the client is willing to update
<A.Wang> Expires November 20, 2010 [Page 7]
Internet-Draft < Notification > May 2010
its ALTO information, it sends the ALTO query message immediately to
get the renewed network/cost map. Otherwise, it may just neglect the
notification and send no more queries. Note that the above ALTO
query message is the same as the current ALTO query message.
+---------------+ +---------------+ +----------------+
|P2P Tracker/ | | | | Network |
|ALTO client | |ALTO server | | condition |
+---------------+ +-------+-------+ +----------------+
| | |
| | Network changing |
| <---------------------+
| | \\ |
| | | Map refresh |
| Notification message| // |
<---------------------|- |
| | |
| | |
| Query message | |
+---------------------> |
| | |
| | |
| Response message | |
<---------------------+ |
3.2. Message format
The notification message format is as below.
For general notification:
<A.Wang> Expires November 20, 2010 [Page 8]
Internet-Draft < Notification > May 2010
Method : 'POST'
URI Path : '/notification'
Or
For specific notification
Method : 'POST'
URI Path : '/notification/costmap'
: '/notification/networkmap'
:??
4. Discussion
4.1. tracker-less p2p situation
The tracker-based and tracker-less p2p application now use different
information distribution algorithm, and then have different impact
on ALTO server for current query/response mechanism and the proposed
notification mechanism. Further research should be devoted on how to
distribute the ALTO information effectively among track-less p2p
peers. If such efficient algorithm can be found, it can then be
used together with the notification mechanism to improve timely the
transport efficiency of tracker-less p2p traffic as well.
One alternative solution to tracker-less situation is that only some
of p2p peers, which have similar capability (for example, have
public IP address and are very stable etc.) as p2p tracker, will be
contacted by the ALTO server directly to get the updated ALTO
information timely. The other part of p2p peers will get the ALTO
information via traditionally query/response manner.
<A.Wang> Expires November 20, 2010 [Page 9]
Internet-Draft < Notification > May 2010
5. Security Considerations
High-level security considerations can be found in the [draft-ietf-
alto-problem-statement].
6. IANA Considerations
This document requests the registration of a new media type:
"application/alto"
7. Acknowledgment
Here we are very appropriate the feedbacks and advices from Richard
Alimi, Reinaldo Penno and Thomson Martin. It is just under their
reviews and comments that make this draft more comprehensive and
acceptable.
8. References
[RFC 5693]
Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
[I-D.ietf-alto-reqs]
S Kiesel, L.Popkin, S.Previdi, R.Woundy, and Y R.
Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-04 (work in
progress),March 2010.
<A.Wang> Expires November 20, 2010 [Page 10]
Internet-Draft < Notification > May 2010
[I-D.ietf-alto-protocol]
R.Alimi, R.Penno and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-03 (work in progress),
March 2010.
Author's Addresses
Aijun Wang
China Telecom Beijing Research Institute
Room 708 No.118, Xizhimenneidajie, xicheng District
Beijing 100035
China
Email: wangaj@ctbri.com.cn
Kai Li
China Telecom Beijing Research Institute
Room 708 No.118, Xizhimenneidajie, xicheng District
Beijing 100035
China
Email: leekai@ctbri.com.cn
Kaiyu Zhou
China Telecom Beijing Research Institute
Room 708 No.118, Xizhimenneidajie, xicheng District
Beijing 100035
China
<A.Wang> Expires November 20, 2010 [Page 11]
Internet-Draft < Notification > May 2010
Email: zhouky@ctbri.com.cn
Xianghui Sun
China Telecom Beijing Research Institute
Room 708 No.118, Xizhimenneidajie, xicheng District
Beijing 100035
China
Email: sunxh@ctbri.com.cn
<A.Wang> Expires November 20, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 15:08:18 |