Re: [Regops] draft-wullink-restful-epp-00.txt

Using HTTP as an additional protocol does add more overhead. requiring the
use of SSL adds even more overhead. I am not quite sure how to mittegate this.

However, using HTTP/REST does allow for a more efficient transport of request and
response data. For some requests there is no need for a request XML message because the
resource URL combined with an HTTP method is sufficient. The same goes for some
response messages. e.g. for the object check response, returning a couple of http headers
instead of a complete EPP xml message makes it more efficient.

The client and the server have to spend much less time creating, validing, marshalling etc of XML messages.
Maybe this will mittegate some of the added overhead, we have not done any measurements but i am
interested in such results. 



________________________________________
Van: Gould, James [[email protected]]
Verzonden: maandag 23 april 2012 18:26
To: Rubens Kuhl; Maarten Wullink
Cc: [email protected]; [email protected]
Onderwerp: Re: [Regops] [provreg] draft-wullink-restful-epp-00.txt

In reading the messages it looks like the two issues with the stateful TCP
session raised include:

1. EPP may pose challenges in load-balanced environments - What has been
raised is load-balancing on a per-command basis instead of a
per-connection basis.  Load balancing the connections distributes the load
fine today.  If there is a need to load balance on a per command basis,
you can keep the state in the gateways and load balance the requests to a
tier of stateless application servers.  The same thing can be done on a
per command type basis, by having the gateways send the commands to the
different set of backend application servers.  The gateways are typically
the least utilized in this scheme, so spreading the load on them doesn't
really solve any problems.  A case was made that stateless would improve
performance, but I believe it will greatly decrease the performance.  I'm
assuming that the security elements still apply (2-way SSL as well as
authentication) which would need to be done on a per-command basis in the
stateless model.  Creating of the 2-way SSL connection even with SSL
session resumption will add a lot of extra overhead on a per command
basis.  Passing the user credentials to authenticate the user on a per
command basis will also add a lot of extra overhead.  Can someone describe
how these elements will be mitigated in a stateless model?  Overall, I
don¹t see how moving from stateful to stateless will benefit either the
client or the server from a performance or load perspective.
2. EPP sessions can wind up in a state where they are no longer linked to
an active TCP session - Can someone describe this issue?


--

JG



James Gould
Principal Software Engineer
[email protected]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







On 4/23/12 11:09 AM, "Rubens Kuhl" <[email protected]> wrote:

>
>Stateless requests also allow for having different pools of servers for
>different types of requests. For instance, mapping "domain info" to
>servers on a read-only database and "domain create" to servers with write
>access to the database. Can improve performance, security, or both.
>
>
>Rubens
>
>
>On Apr 23, 2012, at 11:02 AM, Maarten Wullink wrote:
>
>> Stateless EPP makes it possible to load balance individual EPP requests
>>instead of
>> EPP connections. This should make it easier to distribute to load
>>evenly across the servers.
>> Distributing tcp connections across EPP servers does not guarantee an
>>equal load on every server. This
>> is because not all EPP connections are equal.
>>
>> Also when there is no persistent tcp connection it should be easier to
>>remove
>> a server from the server pool for maintenance without having to
>>disconnect the tcp connections of the
>> clients connected to the server.
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On
>>Behalf Of Gould, James
>> Sent: maandag 23 april 2012 14:43
>> To: Miek Gieben; [email protected]
>> Cc: [email protected]
>> Subject: Re: [provreg] draft-wullink-restful-epp-00.txt
>>
>> This is the first time that I've heard of challenges in load-balanced
>> environments or EPP session state not being linked to an active TCP
>> session.  Can you go into more detail of these issues?  I've been
>>involved
>> with many EPP-based systems through the years and I've never come across
>> any of these issues.  This goes to the heart of the reliability of
>> stateful TCP sessions, which is used with many other protocols.  It
>>would
>> be good to discuss the problems posed prior to consideration of a new
>> stateless version of EPP on top of REST.
>>
>> --
>>
>> JG
>>
>>
>>
>> James Gould
>> Principal Software Engineer
>> [email protected]
>>
>> 703-948-3271 (Office)
>> 12061 Bluemont Way
>> Reston, VA 20190
>> VerisignInc.com
>>
>>
>>
>>
>>
>>
>>
>> On 4/23/12 6:51 AM, "Miek Gieben" <[email protected]> wrote:
>>
>>> Hello,
>>>
>>> [I've cross posted this also to [email protected]]
>>>
>>> SIDN, being the registry for .nl, employs EPP as the primary interface
>>>for
>>> registrars to submit or manipulate domain names. Even though the
>>>protocol
>>> is
>>> working quite well, at SIDN Labs we believed there was room for
>>> improvement.
>>>
>>> Experience over the years revealed certain operational shortcomings in
>>> EPP,
>>> mainly related to the stateful nature of the protocol:
>>>
>>> * EPP may pose challenges in load-balanced environments, when a active
>>> session
>>> has to be switched from one EPP server to another and state is kept on
>>> a per
>>> server basis.
>>>
>>> * EPP sessions can wind up in a state where they are no longer linked
>>>to
>>> an
>>> active TCP connection. This may raise problems in situations where
>>> session
>>> limits are enforced.
>>>
>>> Our draft http://www.ietf.org/id/draft-wullink-restful-epp-00.txt
>>> aims to solve these issues, by proposing a RESTful EPP interface.
>>>
>>> The Abstract reads:
>>>
>>>      This document specifies a 'RESTful interface for EPP' (REPP) with
>>> the
>>>      aim to improve efficiency and interoperability of EPP systems.
>>>
>>>
>>>      This document includes a new EPP Protocol Extension as well as a
>>> mapping
>>>      of [RFC5730] XML-commands to an HTTP based (RESTful) interface.
>>> Existing
>>>      semantics and mappings as defined in [RFC5731], [RFC5732] and
>>> [RFC5733]
>>>      are largely retained and reusable in RESTful EPP.
>>>
>>>
>>>      With REPP, no session is created on the EPP server. Each request
>>> from
>>>      client to server will contain all of the information necessary to
>>>
>>>      understand the request. The server will close the connection after
>>> each
>>>      HTTP request.
>>>
>>>
>>> As the provreg WG is dormant, we have submitted our draft as an
>>>individual
>>> submission.
>>>
>>> Since the provreg mailinglist is still very much alive, we are kindly
>>> requesting
>>> its subscribers to provide us with feedback on our proposal.
>>>
>>> Kind regards,
>>>
>>> --
>>>
>>> Miek Gieben
>>> SIDN Labs
>>> _______________________________________________
>>> provreg mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/provreg
>>
>> _______________________________________________
>> provreg mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/provreg
>>
>> _______________________________________________
>> regops mailing list
>> [email protected]
>> http://nlnetlabs.nl/mailman/listinfo/regops
>
>
>_______________________________________________
>regops mailing list
>[email protected]
>http://nlnetlabs.nl/mailman/listinfo/regops

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg