Subject: [alto] I-D ACTION:draft-ietf-alto-reqs-09.txt

From: [email-masked]
Date: Tue, 10 May 2011 10:30:06 -0700

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization Working Group of the IETF.

    Title         : Application-Layer Traffic Optimization (ALTO) Requirements
    Author(s)     : S. Previdi, et al
    Filename      : draft-ietf-alto-reqs-09.txt
    Pages         : 21
    Date          : 2011-05-10
    
   Many Internet applications are used to access resources, such as
   pieces of information or server processes, which are available in
   several equivalent replicas on different hosts.  This includes, but
   is not limited to, peer-to-peer file sharing applications.  The goal
   of Application-Layer Traffic Optimization (ALTO) is to provide
   guidance to applications, which have to select one or several hosts
   from a set of candidates, that are able to provide a desired
   resource.  This guidance shall be based on parameters that affect
   performance and efficiency of the data transmission between the
   hosts, e.g., the topological distance.  The ultimate goal is to
   improve performance (or Quality of Experience) in the application
   while reducing resource consumption in the underlying network
   infrastructure.

   This document enumerates requirements for ALTO, which should be
   considered when specifying, assessing, or comparing protocols and
   implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-alto-reqs-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 10 May 2011 14:04:22 -0400

The document in my opinion is close to complete. When I look at the
protocol, we are meeting most of the reqs.

But personally I think these 3 Requirements should be modified, or maybe
removed.  But as editor I would like to hear the WG opinions.

My suggestion: Keep it simple. ALTO Server returns the equivalent to 50X (if
not already by HTTP Server).

Let's take them one by one given current HTTP best practices. Just to make
sure we do not require something that can not be operationalized.

"   REQ.  ARv09-34: An ALTO server, which is operating close to its
   capacity limit, MUST be able to inform clients about its impending
   overload situation, and require them to throttle their query rate.

[reinaldo] HTTP Servers (ALTO might likely reuse such infra) do not perform
this function today. They are busy or not (503, 509, etc). They do not
inform clients of 'impending' overload probably due to very fact that this
is a loosely defined term and difficult to predict.

Also, in reality, LBs are used in front of virtually every 'commercial' (for
the lack of a better word) HTTP Server. LBs will send a TCP RST, perform
geo-redirection and whatnot. HTTP Server would not even have the opportunity
to tell about 'impending overload'.

   REQ.  ARv09-35: An ALTO server, which is operating close to its
   capacity limit, MUST be able to inform clients about its impending
   overload situation, and redirect them to another ALTO server.

[reinaldo] Same as above. Moreover we are asking for something that current
HTTP infra is not required to perform. HTTP Servers are not required to
perform redirection if they are busy.

   REQ.  ARv09-36: An ALTO server, which is operating close to its
   capacity limit, MUST be able to inform clients about its impending
   overload situation, and terminate the conversation with the ALTO
   client."

[reinaldo] Okay, this one I interpret as the following. If my ALTO Server is
'impeding' to overload I will go look at all my current ALTO connections and
choose a few to send TCP RST? Again, how to operationalize these
requirements? 

Thanks,

Reinaldo

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 10 May 2011 23:01:11 +0100

Reinaldo,

> removed.  But as editor I would like to hear the WG opinions.

I would agree that as written the requirements you highlight are not very clear and could do with being modified.

It is not clear to me what is meant by "MUST be able to" i.e does this mean the server MUST do it or it MUST be capable of doing it but is allowed to choose not to.

As you mention below "impending overload" is a difficult state to associate clear semantics with.

They also raise the question of what is meant by "close to its capacity limit" i.e. what aspect of its capacity (concurrent TCP connections, CPU cycles to process ALTO request etc.) needs to be covered.

I assume the original intent of the requirements was to provide a capability for ALTO servers to gracefully inform clients that the server is overloaded and inform the client of possible recovery actions?

> not already by HTTP Server).

I would agree. RFC2616 is not prescriptive on the response code to return when a server is overloaded and for 503 response for example states:

      Note: The existence of the 503 status code does not imply that a
      server must use it when becoming overloaded. Some servers may wish
      to simply refuse the connection.

The question in my mind is therefore do we drop the requirements and leave it to implementers to "be nice" or do we try to keep the original intent I assume above and reword the requirements to reflect the intent more precisely, e.g. something like (it probably needs more wordsmithing)

"An ALTO server which is unable to handle a request due to temporary overloading SHOULD inform the client of its overloaded state. Alternatively it MAY redirect them to an alternative ALTO server."

Ben

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 11 May 2011 08:46:01 -0500

[As individual contributor.]

On 05/10/2011 05:01 PM, Ben Niven-Jenkins wrote:
 > The question in my mind is therefore do we drop the requirements and
 > leave it to implementers to "be nice" or do we try to keep the
 > original intent I assume above and reword the requirements to reflect
 > the intent more precisely, e.g. something like (it probably needs
 > more wordsmithing)
 >
 > "An ALTO server which is unable to handle a request due to temporary
 > overloading SHOULD inform the client of its overloaded state.
 > Alternatively it MAY redirect them to an alternative ALTO server."

I think it is always good to be as explicit as possible when
designing protocols.  In no small part, the ambiguity around
the 503 response code in SIP has lead to uncertainty in
determining overload for that protocol.

For an ALTO server, I think we keep the original intent and reword
the requirement to remove any ambiguities.  Working off your
contributed text, here is my suggestion:

   An ALTO server that is unable to service a request due to
   temporary overload SHOULD inform the client of its overload
   state through an appropriate response code.  Alternatively, the
   overloaded ALTO server MAY redirect the client to an
   alternate location.

Plus, Table 1 in draft-ietf-alto-protocol could be updated to
match the requirement as follows:

    | E_OVERLOAD           | 503              | ALTO server overloaded  |

I don't know the semantics of HTTP at a protocol level enough to
determine whether one can put an alternate location in a 503 response.
If so, then a 503/Location provides an unambiguous view of what to
do.

If not, then the HTTP status code of 307 could be used for redirection.
I will leave that to the authors of the protocol draft on whether we
want to include the 307 response code in Table 1 or not.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Richard Alimi <[email-masked]>
Date: Wed, 11 May 2011 08:25:23 -0700

Hi All,

>  overloaded ALTO server MAY redirect the client to an

This sounds good to me.

>   | E_OVERLOAD           | 503              | ALTO server overloaded  |

This is certainly possible, but I'm not sure whether this is a good
idea.  Up to now, the status code here was intended to be for the
ALTO-layer only (e.g., problems with the request syntax, asking for an
invalid cost type even though the client was told that it was not
available).  It seems to me like the overload case is more of an
server concept that we should handle purely in HTTP if at all
possible.

> If so, then a 503/Location provides an unambiguous view of what to

I see no mention that Location can't appear in a 5xx response:
  http://tools.ietf.org/html/rfc2616#section-14.30

Under the spec for the 5xx error codes (and 503 in particular), I
don't see anything that says one can't use a Location header:
  http://tools.ietf.org/html/rfc2616#section-10.5
Indeed, for 503 it suggests that a server can use the Retry-After
header to indicate when it should be retried. It doesn't seem that far
of a leap to suggest an alternate location as well.

Of course, an opinion from someone more familiar with the intricacies
(*cough* Ben, Martin) might be useful here :)

> want to include the 307 response code in Table 1 or not.

I would tend to think that 307 is more of an HTTP-layer concern, and
that we don't need to mention it in the status code table.  The
dependency on RFC2616 should be enough to advise clients that they
should follow redirects.

Rich

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 11 May 2011 10:53:13 -0500

[As individual.]

On 05/11/2011 10:25 AM, Richard Alimi wrote:
[...]
> server concept that we should handle purely in HTTP if at all

Richard: Sure, sounds reasonable.  More inline.

> of a leap to suggest an alternate location as well.

Let's make sure; simply putting a Location header in the 503 may
not cause browsers to follow it.  Probably best to see what Ben
or Martin say.

Regarding the Retry-After header, I don't know whether or not the
HTTP user agents (browsers) honour it uniformly.  In a certain sense,
the Retry-After header leads to a sawtooth behaviour at a server,
with the server alternating between large incoming traffic load
and no incoming traffic load.  This has been shown to cause problems
in SIP, but I am not sure whether I can simply attribute the
same problems to HTTP as well.  We should seek the counsel of
some HTTP folks on this, too.

> dependency on RFC2616 should be enough to advise clients that they

OK; sounds good.

Thanks,

- vijay

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 11 May 2011 18:02:22 +0200

> It is not clear to me what is meant by "MUST be able to" i.e does this mean the server MUST do it or it MUST be capable of doing it but is allowed to choose not to.

the intent of "server MUST be able to..." is: the protocol spec MUST
specify mechanisms, which can be used by the server to ..., or specify
how to use mechanisms of lower protocol layers.

I propose to change the wording of these reqs to be similar to the new
wording about encryption.

Thanks
S.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 11 May 2011 20:03:45 +0100

Vijay, Colleagues,

> not cause browsers to follow it.  Probably best to see what Ben

There's nothing to prevent HTTP 503 responses containing a Location: header.

I haven't tested it but I'd be surprised if browsers (or in fact many other clients) followed it in practice.

> some HTTP folks on this, too.

IMO causing sawtooth behaviour as a result of using Retry-After is because the server has a naive implementation. Sensible use of Retry-After would allow a server to pace requests from clients provided the clients honoured the heading.

RFC2616 is not prescriptive on whether client need to honour Retry-After for 503s. A 503 with a Retry-After is the HTTP equivalent of a "back in 5 mins" sign on a door, there's no guarantee that the server will be back when it says it will and there's nothing to prevent clients from ignoring the sign and continuing to knock.

With the exception of a browser where the user is continuously clicking the retry button I would expect user agents to either treat 503 similar to 500 or to honour the retry-after.

Ben

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 11 May 2011 14:28:25 -0500

On 05/11/2011 02:03 PM, Ben Niven-Jenkins wrote:
> I haven't tested it but I'd be surprised if browsers (or in fact
> many other clients) followed it in practice.

Yes, I agree.  More so given that there is difference among browsers in
interpreting 301/302 uniformly.

> IMO causing sawtooth behaviour as a result of using Retry-After is
> because the server has a naive implementation. Sensible use of
> Retry-After would allow a server to pace requests from clients
> provided the clients honoured the heading.

In the end, no matter how you use R-A header, the result is the
same: the server utilization oscillates between busy load and
no load.  For the period when the server has no load but it has
been quarantined based on the R-A header, it becomes useless and
contributes no goodput to the HTTP farm.

Thanks,

- vijay

---

From: Robert Varga <[email-masked]>
Date: Fri, 13 May 2011 11:06:03 +0200

Hi,

> server concept that we should handle purely in HTTP if at all

The protocol draft allows for clients to retry failed requests (7.5.2),
but does not specify exponential back-off or any such protective measure
on the client side of things. Having a 'back off' error code would allow
the server to indicate the client is retrying too hard. This can
optionally be coupled with optional redirection, which would allow us to
specify the contract explicitly as opposed to relying on HTTP-level
contracts matching our intent.

Thanks,
Robert

---

From: "Williams, Marcus (Contractor)" <[email-masked]>
Date: Fri, 20 May 2011 14:55:51 -0500

> Sent: Friday, May 13, 2011 5:06 AM

> contracts matching our intent.

Perhaps this is a useful protective measure:

If the server has reached a safe load threshold and continues to serve 307 status; the server could optionally indicate cache-control and provide a basis for 408 Request Timeout client error status actions.

Marcus Williams

---

From: Richard Alimi <[email-masked]>
Date: Mon, 23 May 2011 20:48:20 -0700

> contracts matching our intent.

The current spec attempts to push as many of these concerns off to
HTTP as possible.  Do these really need to be ALTO-layer concerns?
Would it be better to suggest extensions to HTTP to achieve desired
backoff behavior here?  It sounds like they might be more generally
useful than just ALTO (if they are not done already, of course).

Thanks,
Rich