Subject: [alto] Comments on draft-kiesel-alto-reqs-01

From: "Roni Even" <[email-masked]>
Date: Thu, 13 Nov 2008 20:03:49 +0200

Hi,

I read the draft and have some comments on section 4.2.

Req 8 recommends an action.  I suggest " An overloaded ALTO server receiving
too many requests should be able to handle the problem e.g. it MAY silently
discard excess requests"

Req 9 is suggested a solution that should be in other document

Req 10 I suggest that it should say that a client shall not overload the
server, the current text is normative text.

Req 11 is normative text and not a requirement.

Req 12 the first part " An ALTO server, which is operating close to its
capacity limit, SHOULD be able to inform clients about its impending
overload situation" is the requirement the rest is normative text.

Thanks

Roni Even

  _____  

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

---

From: Laird Popkin <[email-masked]>
Date: Thu, 13 Nov 2008 14:55:09 -0500 (EST)

Regarding: 

Req 8 recommends an action.  I suggest "   An overloaded ALTO server receiving too many requests should be able to handle the problem e.g. it MAY silently discard excess requests" 

LP: The only requirement (IMO) from the app side regarding ALTO availability is that if ALTO cannot respond to a request that it should do so in an easily identifiable way so that the app doesn't wait "forever" for a response that it's not going to get. (e.g. reply with a 'busy' message, rather than silently not responding) : 

- Laird Popkin, CTO, Pando Networks 
  mobile: 646/465-0570 

----- Original Message ----- 
From: "Roni Even" <[email-masked]> 
To: [email-masked] 
Sent: Thursday, November 13, 2008 1:03:49 PM (GMT-0500) America/New_York 
Subject: [alto] Comments on draft-kiesel-alto-reqs-01 

Hi, 

. 

Req 10 I suggest that it should say that a client shall not overload the server, the current text is normative text. 

Req 12 the first part " An ALTO server, which is operating close to its capacity limit, SHOULD be able to inform clients about its impending overload situation" is the requirement the rest is normative text. 

Thanks 

Roni Even 

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

---

From: stefano previdi <[email-masked]>
Date: Fri, 14 Nov 2008 09:42:13 +0100

> From: Laird Popkin <[email-masked]>
> 
> Regarding: 
> 
> 
> 
> LP: The only requirement (IMO) from the app side regarding ALTO availability
> is that if ALTO cannot respond to a request that it should do so in an easily
> identifiable way so that the app doesn't wait "forever" for a response that
> it's not going to get. (e.g. reply with a 'busy' message, rather than silently
> not responding) :

well, the cause of the inability to respond may also prevent the ALTO server
to send anything back...

s.

> capacity limit, SHOULD be able to inform clients about its impending overload
> situation" is the requirement the rest is normative text.
> 
>   
> 
> Thanks 
> 
> Roni Even 
> 
> 
> _______________________________________________ alto mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/alto

---

From: stefano previdi <[email-masked]>
Date: Fri, 14 Nov 2008 09:43:50 +0100

> it's not going to get. (e.g. reply with a 'busy' message, rather than silently

what if the cause of the inability to respond also prevents the ALTO server
to send anything back?

s.

---

From: Laird Popkin <[email-masked]>
Date: Fri, 14 Nov 2008 04:39:08 -0500 (EST)

That's why I said 'should'. Would it be worth specifying that if an ALTO server is so saturated that it can't even say that it's busy that it reject incoming connections, rather than accept and ignore them? Or is that more detail than protocol specs usually go into? I don't recall seeing that in the RFC's I've read...

----- Original Message -----
From: "stefano previdi" <[email-masked]>
To: "Laird Popkin" <[email-masked]>, "Roni Even" <[email-masked]>
Cc: [email-masked]
Sent: Friday, November 14, 2008 3:43:50 AM (GMT-0500) America/New_York
Subject: Re: [alto] Comments on draft-kiesel-alto-reqs-01

s.

---

From: stefano previdi <[email-masked]>
Date: Fri, 14 Nov 2008 10:43:41 +0100

> That's why I said 'should'. Would it be worth specifying that if an ALTO
> server is so saturated that it can't even say that it's busy that it reject
> incoming connections, rather than accept and ignore them?

maybe. But we can always have the case where an alto server is blocked for
whatever reason (it just hangs) so the client has to handle timeout's
anyway.

> Or is that more 
> detail than protocol specs usually go into? I don't recall seeing that in the
> RFC's I've read...

I believe both protocol and state machinery need to be spec'ed out.

s.

---

From: "Roni Even" <[email-masked]>
Date: Fri, 14 Nov 2008 12:09:24 +0200

Hi,
If the server is discarding messages than the requirement from the protocol will be that there should be timeout defined to discover this case.
Roni Even

----- Original Message -----
From: "stefano previdi" <[email-masked]>
To: "Laird Popkin" <[email-masked]>, "Roni Even" <[email-masked]>
Cc: [email-masked]
Sent: Friday, November 14, 2008 3:43:50 AM (GMT-0500) America/New_York
Subject: Re: [alto] Comments on draft-kiesel-alto-reqs-01

s.

---

From: Sebastian Kiesel <[email-masked]>
Date: Fri, 14 Nov 2008 11:51:54 +0100

Hi,

> > incoming connections, rather than accept and ignore them?

"reject incoming connections" is maybe too specific for some
transport mechanisms, which we have not discussed and ageed on yet... 
Given the level of detail of the other requirements, the overload
control section is maybe already too specific at this point in time,
which is due to the history of the document.

> whatever reason (it just hangs) so the client has to handle timeout's

IMO, REQ. 8, which says that the server MAY discard messages silently,
implies that the client MUST be prepared that his queries remain
unanswered (this can also happen because of other error conditions). And
REQ. 12 says that an overloaded server should better inform clients
explicitly and in advance.

> I believe both protocol and state machinery need to be spec'ed out.

ACK. We may also decide to re-use a protocol that already specifies this.

Thanks,
Sebastian

-- 
Sebastian Kiesel            mailto:[email-masked]
Network Research Division   tel:+49-6221-4342-232   fax:+49-6221-4342-155
NEC Laboratories Europe     Kurfuerstenanlage 36, 69115 Heidelberg, Germany
--
NEC Europe Limited          Registered in England 2832014
Registered Office           NEC House, 1 Victoria Road, London W3 6BL

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 14 Nov 2008 12:30:22 -0600

Just to agree with Stephano, the reason you don't see this kind of protocol 
state machinery more often is because the protocol either runs over TCP 
(which handles a lot of transport state issues for you) or runs over UDP and 
overload behavior gets specified years later (see: SIP :-)

Thanks,

Spencer

----- Original Message ----- 
From: "stefano previdi" <[email-masked]>
To: "Laird Popkin" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 14, 2008 3:43 AM
Subject: Re: [alto] Comments on draft-kiesel-alto-reqs-01

s.

>> overload

---

From: Laird Popkin <[email-masked]>
Date: Fri, 14 Nov 2008 16:45:22 -0500 (EST)

>well, the cause of the inability to respond may also prevent the ALTO server

Certainly true, as a failure case to handle. But it'd be best (IMO) for the spec to define a failure message and encourage it being sent, to improve the odds of not having to wait for timeouts.

---

From: Lars Eggert <[email-masked]>
Date: Sat, 15 Nov 2008 11:45:07 -0600

> overload behavior gets specified years later (see: SIP :-)

At this time, I see no compelling reason why ALTO would need to build  
its own transport protocol, compared to simply running directly on top  
of TCP or indirectly doing so (via HTTP, SOAP, etc.)

Lars

---

From: stefano previdi <[email-masked]>
Date: Sat, 15 Nov 2008 20:27:27 +0100

> From: Lars Eggert <[email-masked]>
> 

I agree, I don't see the need for an alto-specific transport layer.
My point on protocol spec, was related to the alto specifics (req/resp
messages and state machinery).

s.