Subject: Re: [alto] Second round of comments on Re: WGLC on ALTO reqs 10, not 08

From: Martin Stiemerling <[email-masked]>
Date: Tue, 5 Jul 2011 08:37:03 +0000

Reinaldo, 

Here is a text suggestion (to appear in draft-11). Let us know your comments.

3.1.6.  Error Handling and Overload Protection

   REQ.  ARv11-31: An ALTO client protocol MUST use TCP based transport.

   REQ.  ARv11-32: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about an impending or occurring overload situation,
   and require them to throttle their query rate.

   REQ.  ARv11-33: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about an impending or occurring overload situation,
   and redirect them to another ALTO server.

   REQ.  ARv11-34: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about an impending or occurring overload situation,
   and terminate the conversation with the ALTO client.

   REQ.  ARv11-35: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about its inability to answer queries due to technical
   problems or system maintenance, and require them not to send any
   further queries before an indicated point in time.

   REQ.  ARv11-36: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about its inability to answer queries due to technical
   problems or system maintenance, and redirect them to another ALTO
   server.

   REQ.  ARv11-37: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server to
   inform clients about its inability to answer queries due to technical
   problems or system maintenance, and terminate the conversation with
   the ALTO client.

   Note: The existence of the above-mentioned protocol mechanisms does
   not imply that an ALTO server must use them when facing an overload,
   technical problem, or maintenance situation, respectively.  Some
   servers may be unable to use them in that situation, or they may
   prefer to simply refuse the connection or not to send any answer at
   all.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Reinaldo Penno
> Sent: Wednesday, June 29, 2011 3:40 PM
> To: Martin Stiemerling; Sebastian Kiesel; Enrico Marocco
> Cc: [email-masked]
> Subject: Re: [alto] Second round of comments on Re: WGLC on ALTO reqs 10,
> not 08
> 
> 
> 
> 
> On 6/29/11 6:26 AM, "Martin Stiemerling" <[email-masked]>
> wrote:
> 
> > Reinaldo,
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Reinaldo Penno
> >> Sent: Wednesday, June 22, 2011 9:25 AM
> >> To: Sebastian Kiesel; Enrico Marocco
> >> Cc: [email-masked]
> >> Subject: [alto] Second round of comments on Re: WGLC on ALTO reqs 10,
> >> not
> >> 08
> >>
> >> I've sent some emails in the past regarding ARV-31-34 that were
> >> echoed by other people. I still think WGLC can be completed without
> >> changing their text
> >>
> >> For example...
> >>
> >> "   REQ.  ARv10-32: An ALTO client protocol specification MUST specify
> >>    mechanisms, or detail how to leverage appropriate mechanisms
> provided
> >>    by underlying protocol layers, which can be used by an ALTO server
> >>    operating close to its capacity limit, to inform clients about its
> >>    impending overload situation, and require them to throttle their
> >>    query rate.
> >> "
> >>
> >> - Why is 'impending overload'?
> >> - Why clients need to throttle their requests? Throttle how?
> >> Exponetial backoff, etc...
> >
> > I guess the text is fine as it is: this draft is not a protocol
> > specification which needs to specify what the back-off algorithm is.
> 
> If you are requiring clients to throttle then the protocol needs to specify how
> to throttle, the algorithm and others. This makes the client more complex
> without any tangible benefit.
> 
> >
> >>
> >> Others
> >>
> >> - " operating close to its capacity limit". How close?
> >
> > This is neither a matter of the ALTO requirements nor of the ALTO
> > protocol specification but a local configuration of the ALTO server.
> 
> If it is not a matter of requirements can we drop this requirement? The IETF
> does not standardize local policy issues, right?
> 
> >
> >>
> >> This all leads to multiple interpretations and interoperability
> >> issues
> >>
> >> As I mention before we should just use wording similar to HTTP.
> >>
> >> Suggested simpler text
> >>
> >> "...inform the client that the server is currently unable to handle
> >> the request due to a temporary overloading or maintenance of the
> >> server."
> >
> > HTTP is a protocol specification, this draft is a requirements draft.
> 
> It is still making a requirement that is open to interpretation. Why not
> simplify the requirement wording?
> 
> 
> >
> >   Martin
> >
> >>
> >>
> >>
> >> On 6/21/11 8:43 AM, "Sebastian Kiesel" <[email-masked]> wrote:
> >>
> >>> draft-ietf-alto-reqs-10
> >>
> >> _______________________________________________
> >> alto mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/alto
> 
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 5 Jul 2011 06:10:38 -0400

Hi Martin,

Thanks for the update.

In general I find these requirements very repetitive without clear uses
cases to back them. Most of them are exactly the same down to the last
sentence. 

The requirements can be simplified.

- ARv11-32 is a superset of ARv11-35. Saying 'send me one query at every 10
minutes' has the same effect of saying 'come back in 10 minutes'. The
question is what happens after 10 minutes. In this sense, do we need a
requirement for the client protocol to say that now it is okay to resume
'regular' query rate?

- ARv11-36 is a superset of ARv11-33. A overload situation can be considered
a technical problem or he consequence of a technical problem. ARVv11-33 can
be removed

- ARv11-37 is a superset of ARv11-34. A overload situation can be considered
a technical problem or he consequence of a technical problem. ARVv11-34 can
be removed

BTW, none of these requirements are discussed in the protocol as of today.

Is is possible to provide clear use cases for requiring throttling in the
protocol? This requirement came from
http://tools.ietf.org/html/draft-kiesel-alto-reqs-02 and was carried over to
the WG document.

Thanks,

Reinaldo

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 5 Jul 2011 16:22:31 +0200

Reinaldo,

> http://tools.ietf.org/html/draft-kiesel-alto-reqs-02 and was carried over to

Having a P2P swarm of an unknown swarm size sending queries at an
unspecified rate to one focal point (i.e., the more or less centralized
ALTO server) sounded dangerous at that time.

I think the word "overload (situation|control|handling|relief|...)" is
so important that must be mentioned as one requirement and not just
considered to be one special case of error handling. On the other hand,
I am not sure whether we should mandate (MUST) mechanisms that are more
sophisticated than what http provides.

Thanks,
Sebastian

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 5 Jul 2011 10:53:18 -0400

>> http://tools.ietf.org/html/draft-kiesel-alto-reqs-02 and was carried over to

Thanks for chiming in.

> ALTO server) sounded dangerous at that time.

I appreciate where you are coming from but Why would somebody have an ALTO
Server answering queries for a swarm on unknown size in the firs place? It
seems bad dimensioning of the service.

Alternatively if it is an attack, a simple filter on ALTO port on the
untrusted network interface would solve the issue.

> sophisticated than what http provides.

Exactly my point. The issue is that the current wording precludes us from
reusing the HTTP mechanism because it talks about throttling and there is no
such thing in HTTP.

In general all these requirements say "or detail how to how to leverage
appropriate mechanisms provided by underlying protocol layers" but we can
not leverage since the requirements are wider than what HTTP provides.

Thanks,

Reinaldo

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 5 Jul 2011 17:38:23 +0200

Hi Reinaldo,

> seems bad dimensioning of the service.

At that time, and even today, I am not 100% sure what will eventually be
the most relevant use cases for ALTO. There was consensus that ALTO
should be designed in a way that ALTO servers can be operated by parties
other than the network operators.

Maybe some time in the future some people that operate a large
"independent" P2P tracker (independent from ISPs and content owners...)
decide to operate an "independent" ALTO server because they feel that
ISP's "official" ALTO servers are optimizing ISP's transit costs while
penalizing overall swarm throughput. 

In that case you would have peers from swarms of unknown size accessing
the ALTO server. You might want to say "free access is fine but please
not too often".

> not leverage since the requirements are wider than what HTTP provides.

ACK.

Thanks
Sebastian

---

From: Reinaldo Penno <[email-masked]>
Date: Sun, 17 Jul 2011 11:30:00 -0400

> "independent" P2P tracker (independent from ISPs and content owners...)

I'm assuming these are the same people that today operate P2P trackers.
Everything is working fine with HTTP 503, why do you think they will need
something else like 'retry after..' ?

Sorry, I just do not see the use for these requirements.

---

From: Sebastian Kiesel <[email-masked]>
Date: Sun, 17 Jul 2011 22:02:06 +0200

Reinaldo,

> something else like 'retry after..' ?

You're probably right.

However, the purpose of a requirements document is to itemize
requirements that have to be fulfilled and generally not to mandate
specific implementations.

IMO, the requirement is that protocol designers and implementors must
think about dealing with overload situations, in particular about how to
signal server-side overload conditions to clients. HTTP's 503 + R-A is
one way of doing so (but the reqs. doc does not even presume that the
ALTO client protocol is HTTP-based).

> Sorry, I just do not see the use for these requirements.

Can you please be more specific here?

Do you think that the reqs doc should not talk about overload control
at all?

OR

Do you tink the wording is bad or that we are mandating too much, even
in the latest version (11), which explicitly states that a retry-after
based mechansim fulfills the req?

Thanks
Sebastian

---

From: Reinaldo Penno <[email-masked]>
Date: Sun, 17 Jul 2011 18:35:08 -0400

I believe we should have overload requirements but we are mandating too much
. Different from some other IETF protocols, we have years and years of
experience with Web and P2P trackers to help our decision. HTTP 503 is
working fine.

Therefore a simple requirement that can be met with "The server is currently
unavailable (because it is overloaded or down for maintenance)" is fine.

I'm even okay with Retry-After as long as it is optional (MAY) as in
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-15#page-35

Thanks,

Reinaldo