[Int-area] draft-williams-overlaypath-ip-tcp-rfc
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. Cheers, --Brandon Original Message Subject: New Version Notification for draft-williams-overlaypath-ip-tcp-rfc-03.txt Date: Thu, 20 Dec 2012 11:55:33 -0500 From: internet-dra...@ietf.org internet-dra...@ietf.org To: Williams, Brandon bow...@akamai.com A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-03.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Filename:draft-williams-overlaypath-ip-tcp-rfc Revision:03 Title: Overlay Path Option for IP and TCP Creation date: 2012-12-20 WG ID: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-williams-overlaypath-ip-tcp-rfc-03.txt Status: http://datatracker.ietf.org/doc/draft-williams-overlaypath-ip-tcp-rfc Htmlized: http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rfc-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-overlaypath-ip-tcp-rfc-03 Abstract: Data transport through overlay networks often uses either connection termination or network address translation (NAT) in such a way that the public IP addresses of the true endpoint machines involved in the data transport are invisible to each other. This document describes IPv4, IPv6, and TCP options for communicating this information from the overlay network to the endpoint machines. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc
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? -- Wes Eddy MTI Systems ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc
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
Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc
On 12/20/2012 3:49 PM, Brandon Williams wrote: 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. Ah, so are there additional devices beyond what's shown in your Figure 1? I ask because if the overlay ingress and egress are simple tunnel endpoints, then the endpoint addresses would be totally visible to one another. Your figure 1 is: ++ || | INTERNET | || +---+ | ++| | HOST_1 |-| OVRLY_IN_1 |---+| +---+ | ++ || | || +---+ | ++ +---+ | ++ | HOST_2 |-| OVRLY_IN_2 |-| OVRLY_OUT |-| SERVER | +---+ | ++ +---+ | ++ | || +---+ | ++ || | HOST_3 |-| OVRLY_IN_3 |---+| +---+ | ++| || ++ Figure 1 If there were tunnels between the OVRLY_IN and OVERLY_OUT boxes, then the inner IP headers would have the HOST_X and SERVER addresses, and the outer ones in the tunnel would have the overlay headers. Since the inner packets would be delivered ultimately after egressing the tunnels, the HOST_X addresses are totally visible to the server, and vice versa. Your document shows instead: - ip hdr contains: ip hdr contains: SENDER - src = sender -- OVERLAY -- src = overlay2 -- RECEIVER dst = overlay1 dst = receiver - So, this is not really showing tunnels to me ... this is rewriting (NAT) of the destination address. Or am I misunderstanding? -- Wes Eddy MTI Systems ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc
On 12/20/2012 04:04 PM, Wesley Eddy wrote: On 12/20/2012 3:49 PM, Brandon Williams wrote: 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. Ah, so are there additional devices beyond what's shown in your Figure 1? I ask because if the overlay ingress and egress are simple tunnel endpoints, then the endpoint addresses would be totally visible to one another. Yes. There are additional devices between the HOST and OVRLY_IN, and also between OVRLY_OUT and SERVER, but those devices are just the internet's standard routing infrastructure. There are also potential intermediate devices between OVRLY_IN and OVRLY_OUT that can be used for optimized routing between the overlay's ingress and egress. Your figure 1 is: ++ || | INTERNET | || +---+ | ++| | HOST_1 |-| OVRLY_IN_1 |---+| +---+ | ++ || | || +---+ | ++ +---+ | ++ | HOST_2 |-| OVRLY_IN_2 |-| OVRLY_OUT |-| SERVER | +---+ | ++ +---+ | ++ | || +---+ | ++ || | HOST_3 |-| OVRLY_IN_3 |---+| +---+ | ++| || ++ Figure 1 If there were tunnels between the OVRLY_IN and OVERLY_OUT boxes, then the inner IP headers would have the HOST_X and SERVER addresses, and the outer ones in the tunnel would have the overlay headers. Since the inner packets would be delivered ultimately after egressing the tunnels, the HOST_X addresses are totally visible to the server, and vice versa. There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and the inner IP headers will typically use either the client-side addresses or the server-side addresses. However, neither OVRLY_IN nor OVRLY_OUT can be assumed to be reliably in-path between HOST and SERVER, which means that internet routing cannot be relied upon to cause packets to arrive at the overlay ingress. Instead, HOST_1 must directly address OVRLY_IN_1 in order to send its packets into the tunnel, and SERVER must directly address OVRLY_OUT in order to send the return traffic into the tunnel. Your document shows instead: - ip hdr contains: ip hdr contains: SENDER - src = sender -- OVERLAY -- src = overlay2 -- RECEIVER dst = overlay1 dst = receiver - So, this is not really showing tunnels to me ... this is rewriting (NAT) of the destination address. As noted above, the use of tunnels and NAT in this case are not mutually exclusive. NAT is used to allow the overlay ingress to intercept packets, which are then tunneled to the overlay egress, where NAT is used to deliver the packets to the receiver and ensure that return traffic also uses the overlay. --Brandon PS: Sorry to double send this to you Wes. It was bounced by the ietf lists the first time. -- 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
Re: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02
I'm in favor of it. It's a good use case of flow label for L3/4 load balancing. Thanks B.R. Bing -Original Message- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Suresh Krishnan Sent: Tuesday, December 18, 2012 8:46 PM To: Internet Area Cc: Julien Laganier; Ralph Droms Subject: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02 Hi all, This draft has been presented at intarea face to face meetings and has received a bit of discussion. It has been difficult to gauge whether the wg is interested in this work or not. This call is being initiated to determine whether there is WG consensus towards adoption of draft-carpenter-flow-label-balancing-02 as an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-01-04. Regards Suresh Julien ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02
On 12/20/12 5:38 PM, Liubing (Leo) wrote: I'm in favor of it. It's a good use case of flow label for L3/4 load balancing RFC 6437 did not go nearly far enough in my opinion make the flow label suitable for this application. The fact of the matter is if I attempted to use the flow label today as part of a load balancing scheme it would provide zero additional entropy, and what's more I still have to look at the upper layer header. Furthermore the document proposes the use of flow label across muliple flows as a common session key across multiple flows which I personally feel is inconsistent with the notion of a flow, is certainly embedding upper layer (notionally above the l4 header) session information in the layer-3 header and suffers from the exposures described in section 6 of 6437 and making no attempt to ameliorate them. Thanks B.R. Bing -Original Message- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Suresh Krishnan Sent: Tuesday, December 18, 2012 8:46 PM To: Internet Area Cc: Julien Laganier; Ralph Droms Subject: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02 Hi all, This draft has been presented at intarea face to face meetings and has received a bit of discussion. It has been difficult to gauge whether the wg is interested in this work or not. This call is being initiated to determine whether there is WG consensus towards adoption of draft-carpenter-flow-label-balancing-02 as an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-01-04. Regards Suresh Julien ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
