Hi Wes,
Thanks for your comments.
It looks like I might have managed to make the use of the proposed
option less clear, instead of more clear. Or maybe I'm misunderstanding
the point that you're making.
The mechanics of our system are tunnel-based, as with most overlay
architectures that I've looked at. The tunneling starts at an overlay
ingress machine close to one of the endpoints (i.e. the client or
server) and ends at an overlay egress machine close to the other
endpoint. Since the ingress and egress are on the public internet, the
overlay does not extend all the way onto the endpoints' LANs. This means
that standard internet routing cannot be used to drive the connections
into the overlay. Instead, NAT is used on both sides of the overlay,
which results in the server having no way to reliably identify the client.
The proposed options are not intended to be used as part of the
mechanics of the overlay. The overlay is fully functional without the
options. Instead, the options are intended to provide the client's
connection identifying information to the server for use in
load-balancing, diagnostics, etc.
Does this clarify things? further muddy the waters? or simply indicate
that I missed your point?
--Brandon
PS: Thanks for cross-posting your comments. I should have done that to
begin with. I primarily posted to TCPM for informational purposes, since
the TCPM has not shown much interest in this or similar drafts in the
past. The INTAREA list has been more actively engaged in discussion
related to client identification. Still, if I was going to cross-post, I
should have done it with a single thread.
On 12/20/2012 02:16 PM, Wesley Eddy wrote:
On 12/20/2012 12:21 PM, Brandon Williams wrote:
Dear all,
A new version of this draft has been submitted that attempts to lay out
a more clear argument for the use of both TCP and IP options, with
references to other efforts in the same arena.
Comments are welcome.
(note, I've cross-posted to INTAREA and TCPM, since similar
announcements went to each list)
Hi Brandon, *many* thanks for writing this; it does help me (at least)
to understand what you're doing with this option.
As I now understand it, instead of a tunneling approach that would
normally be applied for building overlay networks, this approach
pushes and pops IP addresses from the protocol options fields.
Can you discuss why normal tunneling protocols aren't used to build
the overlay?
Since those are easily and widely available, I wonder why they aren't
used and why something more elaborate, fragile, and not as compatible
with the Internet architecture is really needed or felt to be a good
idea? I understand that it basically *works* ... but just am not
seeing how it makes sense?
--
Brandon Williams; Principal Software Engineer
Cloud Engineering; Akamai Technologies Inc.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
