Subject: [Geopriv] review comments on draft-thomson-geopriv-held-beep-00.txt

From: Andrew Newton <[email-masked]>
Date: Sat, 17 Mar 2007 21:44:19 -0400

http://www.ietf.org/internet-drafts/draft-thomson-geopriv-held- 
beep-00.txt

Overall impression: As of today, too little is likely known about  
these systems to warrant a hammer solution such as a BEEP binding.   
Take it from a guy who has an RFC about another application that has  
a BEEP binding.  This is definitely something that could be done at a  
later date when such an optimization is known to be needed, because  
getting BEEP right is not easy.

1) Since the H in HELD stands for HTTP, I guess the HELD name will  
need changing.  :)

2) The introduction does not completely frame the usage scenario, as  
it uses the word "requester" as the actor making multiple requests.   
It should say "client LIS" or "client LS", as LIS-to-LIS  
communications is where a BEEP binding would be used.  This binding  
makes no sense in Target-as-LR to LIS communications.

3) The justification for using BEEP is that multiple HTTP connections  
are bad.  Why?  Many, many multi-tier servers work this way, with the  
app server maintaining a pool of persistent TCP connections to its  
back-end database.  I remain unconvinced that this BEEP binding is  
anymore efficient for the purpose outlined than multiple HTTP  
connections.

4) The BEEP profile stated does not use the standard BEEP convention,  
and instead overloads the XML NS URN.  That's two sins in one  
registration.

5) There is no discussion of how the serverName attribute gets  
populated, or what happens when the attribute is absent.

6) At least we can agree on Section 6.  :)

-andy

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 18 Mar 2007 04:48:55 -0500

Hi Andy one quick response now.

> anymore efficient for the purpose outlined than multiple HTTP

Our experience with using HTTP in the manner you describe in systems
where requests can each have a different response time is that for a
similar sized system using HTTP you get about have the peak rate of
something BEEP-like. That is not to say that you cannot perhaps tweak an
HTTP system to improve performance, but I remain unconvinced that you
can tweak to get a 100% increase in performance.

The problem is of course dimensioning enough threads and ensuring that
you don't get queuing of low-delay requests immediately after
delay-tolerant requests thereby failing to meet QoS. You also need to
avoid queuing multiple delay-tolerant requests to avoid starving.

Cheers
James

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Andrew Newton <[email-masked]>
Date: Sun, 18 Mar 2007 08:58:59 -0400

> avoid queuing multiple delay-tolerant requests to avoid starving.

If you are suggesting that TCP congestion control doesn't work with a  
high number of TCP connections, I'll let you argue that with the  
Transport folks... I'm not saying that is either wrong or right.

However, BEEP's channel multiplexing over a single TCP connection  
doesn't seem to solve the problem you are talking about.  It simply  
lifts the problem one layer up.  Perhaps your HTTP implementation  
needed some tweaking.

If you are saying that your implementation partitions the channels  
into sets of pools based on the characteristic of the query, that can  
also been done with HTTP/TCP pools as well.  And I'd note, the HELD/ 
BEEP draft does not mention that.

-andy