One document matched: draft-roome-alto-incr-update-sse-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "http://http://tools.ietf.org/tools/templates/rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc iprnotified="no" ?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std"
docName="draft-roome-alto-incr-update-sse-00"
ipr="trust200902">
<front>
<title abbrev="ALTO Incremental Updates">ALTO Incremental Updates Using Server-Sent Events (SSE)</title>
<author initials="W." surname="Roome" fullname="Wendy Roome">
<organization abbrev="Alcatel-Lucent">Alcatel-Lucent/Bell Labs</organization>
<address>
<postal>
<street>600 Mountain Ave, Rm 3B-324</street>
<city>Murray Hill</city>
<region>NJ</region>
<code>07974</code>
<country>USA</country>
</postal>
<phone>+1-908-582-7974</phone>
<email>w.roome@alcatel-lucent.com</email>
</address>
</author>
<author initials="X." surname="Shi" fullname="Xiao Shi">
<organization abbrev="Yale University">Yale University</organization>
<address>
<postal>
<street>51 Prospect Street</street>
<city>New Haven</city>
<region>CT</region>
<code>06511</code>
<country>USA</country>
</postal>
<email>xiao.shi@yale.edu</email>
</address>
</author>
<author fullname="Y. Richard Yang" initials="Y." surname="Yang">
<organization>Yale University</organization>
<address>
<postal>
<street>51 Prospect St</street>
<city>New Haven</city>
<code>CT</code>
<country>USA</country>
</postal>
<email>yang.r.yang@gmail.com</email>
</address>
</author>
<date month="October" year="2014"/>
<area>Networks</area>
<workgroup>ALTO WG</workgroup>
<keyword>ALTO</keyword>
<abstract>
<t>The goal of Application-Layer Traffic Optimization (ALTO)
<xref target="RFC7285"/> is to
bridge the gap between network and applications by providing
network related information to non-priviledged, application-level clients.
This allows applications to make informed decisions,
for example when selecting a target host
from a set of candidates.</t>
<t>Therefore an ALTO Server provides network and cost maps to its
clients. However, those maps can be very large,
and portions of those maps may change frequently
(cost maps in particular).</t>
<t>This draft presents a method to provide incremental
updates for these maps. The goal is to reduce the load
on the ALTO Client and Server by transmitting just the
updated portions of those maps.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
The Application-Layer Traffic Optimization (ALTO)
<xref target="RFC7285"/> protocol
provides network related information to client
applications so that clients may make informed
decisions. An ALTO Server provides network and cost
maps, which may be very large and change very
frequently.
</t>
<t>
Instead of having the clients request for a new complete network map or
cost map every time, an incremental update from the server is much more
efficient. The goals are to reduce the load on the ALTO Client and Server
by efficiently transmitting only the updated portions of those maps,
and to provide timely updates to clients.
</t>
<t>
This draft uses the JSON Merge Patch message format
<xref target="RFC7386"/> to encode the
incremental update messages for network maps and cost maps,
and uses Server-Sent Events (SSE) as the transport mechanism
to deliver those updates to clients.
</t>
</section>
<section title="Incremental Update Message Format">
<section title="JSON Merge Patch">
<t>
<xref target="RFC7386"/> defines JSON Merge Patch format and
transport, which enables applications to update the
server resources via the PATCH method <xref target="RFC5789"/> of HTTP.
This draft adopts the format of the Merge Patch
messages to encode our incremental updates objects,
but uses a different transport mechanism.
</t>
<t>
The process of applying a Merge Patch is defined by the following algorithm,
as specified in <xref target="RFC7386"/>:
</t>
<figure>
<artwork><![CDATA[
define MergePatch(Target, Patch) {
if Patch is an Object {
if Target is not an Object {
Target = {} # Ignore the contents and
# set it to an empty Object
}
for each Name/Value pair in Patch {
if Value is null {
if Name exists in Target {
remove the Name/Value pair from Target
}
} else {
Target[Name] = MergePatch(Target[Name], Value)
}
}
return Target
} else {
return Patch
}
}
]]></artwork>
</figure>
<t>
Note that null as the value of a name/value pair will
remove the pair with "name" in the original JSON
document.
</t>
</section>
<section title="JSON Merge Patch Applied to Network Map Messages">
<t>
Section 11.2.1.6 of <xref target="RFC7285"/> defines the format
of a Network Map message. Here is a simple example:
</t>
<figure>
<artwork><![CDATA[
{
"meta" : {
"vtag": {
"resource-id": "my-default-network-map",
"tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
]
},
"PID2" : {
"ipv4" : [ "198.51.100.128/25" ]
},
"PID3" : {
"ipv4" : [ "0.0.0.0/0" ],
"ipv6" : [ "::/0" ]
}
}
}
]]></artwork>
</figure>
<t>
When applied to that message, the following Merge Patch update message
adds the ipv6 prefix "2000::/3" to "PID1",
deletes "PID2",
and assigns a new "tag" to the Network Map:
</t>
<figure>
<artwork><![CDATA[
{
"meta" : {
“vtag” : {
"tag" : "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
}
},
"network-map": {
"PID1" : {
"ipv6" : [ "2000::/3" ]
},
"PID2" : null
}
}
]]></artwork>
</figure>
<t>
Here is the updated Network Map:
</t>
<figure>
<artwork><![CDATA[
{
"meta" : {
"vtag": {
"resource-id": "my-default-network-map",
"tag": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
],
"ipv6" : [ "2000::/3" ]
},
"PID3" : {
"ipv4" : [ "0.0.0.0/0" ],
"ipv6" : [ "::/0" ]
}
}
}
]]></artwork>
</figure>
</section>
<section title="JSON Merge Patch Applied to Cost Map Messages">
<t>
Section 11.2.3.6 of <xref target="RFC7285"/> defines the format
of a Cost Map message. Here is a simple example:
</t>
<figure>
<artwork><![CDATA[
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
}
],
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID2": 15 }
}
}
]]></artwork>
</figure>
<t>
The following Merge Patch message updates that cost map
so that (1) PID1->PID2 is 9 instead of 5; (2)
PID3->PID1 is no longer available;
and (3) PID3->PID3 is now 1:
</t>
<figure>
<artwork><![CDATA[
{
"cost-map" : {
"PID1" : { "PID2" : 9 },
"PID3" : { "PID1" : null, "PID3" : 1 }
}
}
]]></artwork>
</figure>
<t>
Here is the updated Cost Map:
</t>
<figure>
<artwork><![CDATA[
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
}
],
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": 1, "PID2": 9, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID3": 1 }
}
}
]]></artwork>
</figure>
</section>
</section>
<section title="Server-Sent Events">
<section title="Overview of SSEs">
<t>
Server-Sent Events <xref target="SSE"/> enable a server
to send new data to a client by pushing messages to the
client. To summarize the protocol, the client establishes
an HTTP connection to the server, and keeps the connection open.
The server continually sends messages. Messages are delimited
by two new-lines (this is a slight simplification of the
full specification), and contain three fields:
an event type, an id, and data. All fields are strings.
The data field may contain new-lines; the other fields cannot.
The event type and id fields are optional.
</t>
<t>
Here is a sample SSE stream, starting with the client request.
The server sends three events and then closes the stream.
</t>
<figure>
<artwork><![CDATA[
GET /stream HTTP/1.1
Host: example.com
Accept: text/event-stream
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream
event: start
data: hello there
event: middle
data: let's chat some more ... and more ...
event: end
data: good bye
]]></artwork>
</figure>
</section>
<section title="ALTO SSE Update Messages" anchor="ALTO.SSE.Messages">
<t>
In our events, the data field is a JSON object.
There two types of data objects.
One is a message describing an ALTO resource, such as a Network Maps or Cost Map,
as defined in <xref target="RFC7285"/>.
We will refer to these as full-map messages.
The other type is a Merge Patch message
to apply to an ALTO resource.
</t>
<t>
Our event types have two sub-fields:
the media-type of the JSON message in the data field,
and the resource-id of the ALTO resource.
The media-types for ALTO resource messages are defined by <xref target="RFC7285"/>,
and include "application/alto-networkmap+json" for Network Map messages
and "application/alto-costmap+json" for Cost Map messages.
The media-type for a Merge Patch message is "application/merge-patch+json",
and is defined by <xref target="RFC7285"/>.
</t>
<t>
We do not use the SSE id field.
</t>
<t>
Because commas (character code 0x2c) are not allowed in media-type names,
we encode the event type sub-fields as
</t>
<figure>
<artwork><![CDATA[
media-type , resource-id
]]></artwork>
</figure>
<t>
Here examples of ALTO update events:
</t>
<figure>
<artwork><![CDATA[
event: application/alto-networkmap+json,my-network-map
data: { ... full Network Map message ... }
event: application/alto-costmap+json,my-routingcost-map
data: { ... full Cost Map message ... }
event: application/merge-patch+json,my-routingcost-map
data: { ... Merge Patch update for previous Cost Map ... }
]]></artwork>
</figure>
</section>
<section title="Keep-Alive Messages">
<t>
An SSE event with an empty event type is a keep-alive message.
An ALTO Server MAY send keep-alive messages as needed.
An ALTO Client MUST ignore any keep-alive messages.
</t>
</section>
</section>
<section title="Update Stream Service" anchor="UpdateStreamService">
<t>
An Update Stream Service returns a stream of SSE messages,
as defined in <xref target="ALTO.SSE.Messages"/>.
</t>
<section title="Media Type">
<t>
The media type of an ALTO Update Stream resource is "text/event-stream".
</t>
</section>
<section title="HTTP Method">
<t>
An ALTO Update Stream resource is requested using the HTTP GET method.
</t>
</section>
<section title="Accept Input Parameters">
<t>
None.
</t>
</section>
<section title="Capabilities">
<t>
The capabilities are defined by an object of type UpdateStreamCapabilities:
</t>
<figure>
<artwork><![CDATA[
object {
JSONString events<1..*>;
} UpdateEventStreamCapabilities;
]]></artwork>
</figure>
<t>
The strings in the array are the event types (see <xref target="ALTO.SSE.Messages"/>)
sent by this Update Stream.
</t>
<t>
If an Update Event Service's event capability list
has an event with a media-type of "text/merge-patch+json"
for a resource-id,
then the event capability list MUST also have an full-map event
for that resource-id.
For example, suppose "my-costmap" is the resource-id of a Cost Map.
Then if the event list has "text/merge-patch+json,my-costmap",
it MUST also have the event "application/alto-costmap+json,my-costmap".
</t>
</section>
<section title="Uses">
<t>
An array with the resource-ids of the resources for which this stream sends updates.
This array MUST contain the resource-ids of every event type
in the "events" capability.
</t>
</section>
<section title="Event Order Requirements">
<t>
There are several requirements on the order in which an ALTO Server
sends SSE Update messages on the event stream:
<list style="symbols">
<t>
For any given resource-id, the ALTO Server MUST send
a full-map update event (media-type "application/alto-networkmap+json"
or "application/alto-costmap+json") before the first
Merge Patch event (media-type "application/merge-patch+json")
for that resource-id.
</t>
<t>
The ALTO Server SHOULD send full-map update events
for all resource-ids covered by this Update Stream resource
as soon as possible after the client initiates the connection.
</t>
<t>
If the event list contains a resource-id R0
on which resource-id R1 depends,
when R0 changes, the ALTO Server MUST send the update for R0
before sending the update for R1.
For example, suppose the event list includes a Network Map resource
and its dependent Cost Map resources.
When the Network Map changes, the ALTO Server MUST
send an update event for that Network Map
before sending the update events for the dependent Cost Maps.
</t>
<t>
If the event list contains a resource-id R0
on which resource-id R1 depends,
the ALTO Server SHOULD send an update for R1
as soon as possible after sending the update for R0.
For example, when a Network Map changes, the ALTO Server SHOULD
send update events for all dependent Cost Maps
as soon as possible after the update event for the Network Map.
</t>
</list>
</t>
</section>
<section title="Response">
<t>
Here is an example of a client's request and the server's immediate response,
using the Update Stream resource "my-routingcost-update-stream"
defined in the IRD in <xref target="IRD.example"/>.
This assumes the Update Stream service sends updates
for a Network Map with resource-id "my-network-map"
and an associated Cost Map with resource-id "my-routingcost-map":
</t>
<figure>
<artwork><![CDATA[
GET /updates/routingcost HTTP/1.1
Host: alto.example.com
Accept: text/event-stream
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream
event: application/alto-networkmap+json,my-network-map
data: { ... full Network Map message ... }
event: application/alto-costmap+json,my-routingcost-map
data: { ... full Cost Map message ... }
]]></artwork>
</figure>
<t>
After sending those two events immediately,
the ALTO Server will send additional events
as the maps change. For example, the following
represents a small change to the Cost Map:
</t>
<figure>
<artwork><![CDATA[
event: {"resource-id":"my-routingcost-map",
"media-type":"application/merge-patch+json"}
data: {"cost-map": {"PID1" : {"PID2" : 9}}}
]]></artwork>
</figure>
<t>
If a major change to the Network Map occurs,
the ALTO Server MAY choose to send
full Network and Cost Map messages
rather than Merge Patch messages:
</t>
<figure>
<artwork><![CDATA[
event: application/alto-networkmap+json,my-network-map
data: { ... full Network Map message ... }
event: application/alto-costmap+json,my-routingcost-map
data: { ... full Cost Map message ... }
]]></artwork>
</figure>
</section>
<section title="Client Actions When Receiving Update Messages">
<t>
In general, when a client receives a full-map update message
for a resource, the client should replace the current version
with the new version.
When a client receives a Merge Patch update message
for a resource, the client should apply those patches
to the current version of the resource.
</t>
<t>
However, because resources can depend on other resources
(e.g., Cost Maps depend on Network Maps),
an ALTO Client MUST NOT use a dependent resource
when the resource on which it depends changes.
There are at least two ways a client may do that.
We will illustrate these techniques by referring to Network and Cost Map messages,
although these techniques apply to any dependent resources.
</t>
<t>
One approach is for the ALTO Client to save
the Network Map update message in a buffer,
and continue to use the previous Network Map,
and the associated Cost Maps,
until the client receives the update messages
for all dependent Cost Maps.
The client then applies all Network and Cost Map updates atomically.
</t>
<t>
Alternatively, the client MAY update the Network Map immediately.
In this case, the client MUST mark each dependent Cost Map as
temporarily invalid, and MUST NOT use that map
until the client receives a Cost Map update message
with the new Network Map version tag.
Note that the client MUST NOT delete the Cost Maps,
because the server may send Merge Patch update messages.
</t>
<t>
The ALTO Server SHOULD send updates to dependent resources in a timely fashion.
However, if the client does not receive the expected updates,
the client MUST close the Update Stream connection,
discard the dependent resources,
and reestablish the Update Stream.
If the client uses the Filtered Update Stream service,
the client MAY retain the version tag of the last version of any tagged resources,
and give those version tags when requesting the new Update Stream.
In this case, if a version is still current, the ALTO Server
will not re-send that resource.
</t>
<t>
Although not as efficient as possible, this recovery method is simple and reliable.
</t>
</section>
</section>
<section title="Filtered Update Stream Service">
<t>
The Filtered Update Stream service is similar to
the Update Stream service, except that the client
can select the types of update events.
Specifically, except as noted below,
the Filtered Update Stream service is identical to
the Update Stream service (<xref target="UpdateStreamService"/>).
</t>
<section title="HTTP Method">
<t>
A Filtered ALTO Update Stream resource
is requested using the HTTP POST method.
</t>
</section>
<section title="Accept Input Parameters" anchor="FilteredUpdate.media-type">
<t>
An ALTO Client supplies filtering parameters by specifying media type
"application/alto-updatestreamfilter+json" with HTTP POST body
containing a JSON object of type ReqFilteredUpdateStream, where:
</t>
<figure>
<artwork><![CDATA[
object {
[UpdateEventType events<1..*>;]
[VersionTag vtags<1..*>;]
[ResourceInputs inputs<1..*>;]
} ReqFilteredUpdateStream;
object-map {
ResourceID -> JSONObject;
} ResourceInputs;
]]></artwork>
</figure>
<t>
The "events" field gives the types of the events the ALTO Client wishes to receive.
These events MUST be a subset of the "events" capability of this resource.
If the "events" list is omitted, the ALTO Server MUST send all event types
in the "events" capability of this resource.
</t>
<t>
The "vtags" field gives the version tags,
as defined in Section 10.3 of <xref target="RFC7285"/>,
for any resources which the client already has.
If those versions are still current,
the server SHOULD NOT send the full version of that resource
at startup.
</t>
<t>
The "inputs" field gives the client input needed for any POST-mode resources
requested by the client.
The value is a JSON object; the key is the resource-id of the POST-mode resource,
and the value is the JSON object that it requires as "accepts" input.
</t>
<t>
If a client requests Merge Patch update events for a given resource-id,
the client MUST also request the corresponding full map update events
for that resource-id.
</t>
<t>
If a client requests the full-map update event for given resource-id,
but does not request the Merge Patch update event for that resource-id,
then the ALTO Server MUST send full-map update events whenever
the map changes. For Network Map resources, the ALTO Server SHOULD
send the full map as soon as it would have sent the Merge Patch event.
For Cost Map and other resources, the ALTO Server MAY delay sending the full-map
until more changes are available.
</t>
</section>
<section title="Response">
<t>
Here is an example of a client's request and the server's immediate response,
using the Filtered Update Stream resource "my-allresources-update-stream"
defined in the IRD in <xref target="IRD.example"/>.
The client requests updates for the Network Map
and the "routingcost" Cost Map,
but does not want updates for the "hopcount" Cost Map.
The "vtags" field gives the client's version of the Network Map.
Because that version is still current,
the server does not send the full Network Map update event
at the beginning of the stream:
</t>
<figure>
<artwork><![CDATA[
POST /updates/allresources HTTP/1.1
Host: alto.example.com
Accept: text/event-stream
Content-Type: application/alto-updatestreamfilter+json
Content-Length: ###
{ "events": [
"application/alto-networkmap+json,my-network-map",
"application/alto-costmap+json,my-routingcost-map",
"application/merge-patch+json,my-routingcost-map"
],
"vtags": [
"resource-id": "my-network-map", "tag": "314159265359"}
]
}
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream
event: application/alto-costmap+json,my-routingcost-map
data: { ... full Cost Map message ... }
]]></artwork>
</figure>
<t>
After that, the ALTO Server sends updates for the Network Map
and "routingcost" Cost Map as they become available.
</t>
<t>
As another example, here is how a client can request updates
for the property "priv:ietf-bandwidth" for a set of endpoints.
The ALTO Server immediately sends a full-map message with
the property values for all endpoints.
After that, the server sends update events
for the individual endpoints as their property values change.
</t>
<figure>
<artwork><![CDATA[
POST /updates/allresources HTTP/1.1
Host: alto.example.com
Accept: text/event-stream
Content-Type: application/alto-updatestreamfilter+json
Content-Length: ###
{ "events": [
"application/alto-endpointprop+json,my-properties",
"application/merge-patch+json,my-properties"
],
"inputs": {
"my-properties": {
"properties" : [ "priv:ietf-bandwidth" ],
"endpoints" : [
"ipv4:1.0.0.1",
"ipv4:1.0.0.2",
"ipv4:1.0.0.3"
]
}
}
}
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream
event: application/alto-endpointprop+json,my-properties
data: { "endpoint-properties": {
data: "ipv4:1.0.0.1" : { "priv:ietf-bandwidth": "13" },
data: "ipv4:1.0.0.2" : { "priv:ietf-bandwidth": "42" },
data: "ipv4:1.0.0.3" : { "priv:ietf-bandwidth": "27" }
data: } }
event: text/merge-patch+json,my-properties
data: { "endpoint-properties":
data: {"ipv4:1.0.0.1" : {"priv:ietf-bandwidth": "3"}}
data: }
event: text/merge-patch+json,my-properties
data: { "endpoint-properties":
data: {"ipv4:1.0.0.3" : {"priv:ietf-bandwidth": "38"}}
data: }
]]></artwork>
</figure>
</section>
</section>
<section title="IRD Example" anchor="IRD.example">
<t>
Here is an example of an IRD that offers both regular and Filtered
Update Stream services.
The unfiltered Update Stream
provides updates for the Network Map
and "routingcost" Cost Map.
The Filtered Update Stream
provides update to both those maps,
plus the "hopcount" Cost Map
and the Endpoint Properties service.
</t>
<figure>
<artwork><![CDATA[
"my-network-map": {
"uri": "http://alto.example.com/networkmap",
"media-type": "application/alto-networkmap+json",
},
"my-routingcost-map": {
"uri": "http://alto.example.com/costmap",
"media-type": "application/alto-costmap+json",
"uses": ["my-networkmap+json"],
"capabilities": {
"cost-type-names": ["num-routingcost"]
}
},
"my-hopcount-map": {
"uri": "http://alto.example.com/costmap",
"media-type": "application/alto-costmap+json",
"uses": ["my-networkmap+json"],
"capabilities": {
"cost-type-names": ["num-hopcount"]
}
},
"my-properties": {
"uri": "http://alto.example.com/properties",
"media-type": "application/alto-endpointprops+json",
"accepts": "application/alto-endpointpropparams+json",
"capabilities": {
"prop-types": ["priv:ietf-bandwidth"]
}
},
"my-routingcost-update-stream": {
"uri": "http://alto.example.com/updates/routingcost",
"media-type": "text/event-stream",
"uses": ["my-network-map", "my-routingcost-map"],
"capabilities": {
"events": [
"application/alto-networkmap+json,my-network-map",
"application/alto-costmap+json,my-routingcost-map",
"application/merge-patch+json,my-routingcost-map"
]
}
},
"my-allresources-update-stream": {
"uri": "http://alto.example.com/updates/allresources",
"media-type": "text/event-stream",
"uses": [
"my-network-map",
"my-routingcost-map",
"my-hopcount-map",
"my-properties"
],
"accepts": "application/alto-updatestreamfilter+json",
"capabilities": {
"events": [
"application/alto-networkmap+json,my-network-map",
"application/alto-costmap+json,my-routingcost-map",
"application/merge-patch+json,my-routingcost-map"
"application/alto-costmap+json,my-hopcount-map",
"application/merge-patch+json,my-hopcount-map"
"application/alto-endpointprops+json,my-properties",
"application/merge-patch+json,my-properties"
]
}
}
]]></artwork>
</figure>
</section>
<section title="Design Decisions and Discussion">
<section title="Not Allowing Stream Restart">
<t>
If an update stream is closed accidentally,
when the client reconnects, the server must
resend the full maps.
This is clearly inefficient.
To avoid that inefficiency,
the SSE specification allows a server to assign an id
to each event. When a client reconnects,
the client can present the id of the last successfully
received event, and the server restarts with the
next event.
</t>
<t>
However, that mechanism adds a lot of complication.
The server would have to save SSE messages in a buffer,
in case clients reconnect.
But that mechanism will never be perfect:
if the client waits too long to reconnect,
or if the client's last id is bogus,
then the server will have to resend the complete maps anyway.
</t>
<t>
In short, using event ids to avoid resending the full map
adds a lot of complication to avoid a situation which is
hopefully very rare. Hence we decided to keep it simple.
</t>
<t>
The Filtered Update Stream service does allow the client
to specify the vtag of the last received Network Map,
and if that is still current, the server can avoid
retransmitting the Network Map.
</t>
</section>
<section title="Is Incremental Update Useful for Network Maps?">
<t>
It is not clear whether incremental update (that is, Merge Patch update)
is useful for Network Maps. For minor changes, such as moving a prefix
from one PID to another, it might be useful. But more involved changes
to the Network Map are likely to be "flag days": they represent a completely
new Network Map, rather than a simple, well-defined change.
</t>
<t>
This is not to say that Network Map updates are not useful.
Clearly Network Maps will change, and update events are necessary
to inform clients of the new map.
But we expect most Network Map updates will be full updates
with full Network Map message, rather than incremental Merge Patch
updates.
</t>
<t>
Note that while we allow a server to use Merge Patch on Network Maps,
we do not require the server to do so.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
Allowing persistent update stream connections
does enable a new class of Denial-of-Service attacks.
An ALTO Server MAY choose to limit the number of active streams,
and reject new requests when that threshold is reached.
In this case the server should return
the HTTP status "503 Service Unavailable".
</t>
<t>
Alternatively an ALTO Server MAY return
the HTTP status "307 Temporary Redirect"
to redirect the client to another ALTO Server
which can better handle a large number of update streams.
</t>
<t>
This extension does not introduce any privacy issues
not already present in the ALTO protocol.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This draft defines a new media-type, "application/alto-updatestreamfilter+json",
as described in <xref target="FilteredUpdate.media-type"/>.
That type must be registered with IANA.
</t>
<t>
All other media-types used in this document have already been registered,
either for ALTO or JSON Merge Patch.
</t>
</section>
</middle>
<back>
<references>
<!--
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials="T." surname="Narten" fullname="T. Narten"/>
<author initials="H." surname="Alvestrand" fullname="H. Alvestrand"/>
<date month="May" year="2008"/>
</front>
<seriesInfo name="RFC" value="5226" />
<seriesInfo name="BCP" value="26" />
</reference>
-->
<reference anchor='RFC2119'>
<front>
<title abbrev='HTTP'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner' />
<date year='1997' month='March' />
</front>
<seriesInfo name='RFC' value='2119' />
<seriesInfo name='BCP' value='14' />
<format type='TXT' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
</reference>
<reference anchor="RFC5789">
<front>
<title>PATCH Method for HTTP</title>
<author initials="L." surname="Dusseault" fullname="L. Dusseault"/>
<author initials="J." surname="Snell" fullname="J. Snell"/>
<date month="March" year="2010"/>
</front>
<seriesInfo name="RFC" value="5789" />
</reference>
<reference anchor="RFC7159">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials="T." surname="Bray" fullname="T. Bray"/>
<date month="March" year="2014"/>
</front>
<seriesInfo name="RFC" value="7159" />
</reference>
<reference anchor="RFC7285">
<front>
<title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
<author initials="R." surname="Almi" fullname="R. Alimi"/>
<author initials="R." surname="Penno" fullname="R. Penno"/>
<author initials="Y." surname="Yang" fullname="Y. Yang"/>
<author initials="S." surname="Kiesel" fullname="S. Kiesel"/>
<author initials="S." surname="Previdi" fullname="S. Previdi"/>
<author initials="W." surname="Roome" fullname="W. Roome"/>
<author initials="S." surname="Shalunov" fullname="S. Shalunov"/>
<author initials="R." surname="Woundy" fullname="R. Woundy"/>
<date month="September" year="2014"/>
</front>
<seriesInfo name="RFC" value="7285" />
</reference>
<reference anchor="RFC7386">
<front>
<title>JSON Merge Patch</title>
<author initials="P." surname="Hoffman" fullname="P. Hoffman"/>
<author initials="J." surname="Snell" fullname="J. Snell"/>
<date month="October" year="2014"/>
</front>
<seriesInfo name="RFC" value="7386" />
</reference>
<reference anchor="SSE">
<front>
<title>Server-Sent Events (W3C)</title>
<author initials="I." surname="Hickson" fullname="Ian Hickson"/>
<date month="December" year="2012"/>
</front>
<!-- http://www.w3.org/TR/eventsource/ -->
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:20:30 |