search

quicwg / load-balancers

In-progress version of draft-ietf-quic-load-balancers
https://quicwg.org/
Other
34 stars 10 forks source link

Any suggestion about transmit client ip from quic-lb to quic-server? #51

Closed Neo-ZK closed 3 years ago

Neo-ZK commented 4 years ago

Dear author: As you know, in many production scenarios, quic-server need to know the real ip/port of client. But when there is a quic-lb in the middle(a fullnat quic-lb), there are not any standard way to implement this function. Actually this function is not difficult to implement, will quic-lb-draft suggest or define a standard way for this function later?

martinduke commented 4 years ago

That is not currently an objective for this document. I would probably start with taking the PROXY protocol and adapting it for UDP. Perhaps that would be a good draft!

Neo-ZK commented 4 years ago

Ah, I got it

Neo-ZK commented 4 years ago

Um...I reconsider the situation, can UDP-PROXY-protocol cover all UDP-based transport protocol? Consider this, for QUIC, we may send client ip to quic-server when receive initial packet. For RTP, we may send client ip to real-server when receive first packet... There are so much UDP-based protocol, can all situation be covered in one draft?

martinduke commented 4 years ago

Yes

On Wed, Sep 2, 2020 at 7:41 AM ZengKe notifications@github.com wrote:

Um...I reconsider the situation, can UDP-PROXY-protocol cover all UDP-based transport protocol? Consider this, for QUIC, we may send client ip to quic-server when receive initial packet. For RTP, we may send client ip to real-server when receive first packet...

There are so much UDP-based protocol, can all situation be covered in one draft?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/quicwg/load-balancers/issues/51#issuecomment-685782202, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF2EYENV43NSOGCBLX3E6D3SDZKSBANCNFSM4QM75G5Q .

Neo-ZK commented 4 years ago

👌 Looking forward to your draft, by the way, could you please tell me when will you start writing this draft?

martinduke commented 4 years ago

I'm not sure I volunteered to write it!

On Thu, Sep 3, 2020 at 7:35 PM ZengKe notifications@github.com wrote:

👌 Looking forward to your draft, by the way, could you please tell me when will you start writing this draft?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/quicwg/load-balancers/issues/51#issuecomment-686864678, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF2EYEPEQZKXFOUPYOUAIDTSEBG6FANCNFSM4QM75G5Q .

Neo-ZK commented 4 years ago

I'm not sure I volunteered to write it!

Ah, if you have any interests to do this, I would like to do some contribution about it

Neo-ZK commented 4 years ago

Furthermore, I think it's a very important function for production environment

Lingtaonju commented 4 years ago

Is it possible that in quic lb, only a special proxy protocol is designed for quic, such as carrying pp packet only for initial packet, so as to avoid per-packet carrying to reduce overhead ?

martinduke commented 3 years ago

IMO Proxy Protocol is a NAT function, not a load balancing function. I don't think it belongs in this draft. I do have an individual draft (quic-natsupp) that touches on some issues with QUIC NATs, and this could house this work, but I think it'd be better just to write a draft that describes this.

I'll also note that the latest proxy protocol spec seems to offer UDP support, if I'm reading it correctly: https://developers.cloudflare.com/spectrum/getting-started/proxy-protocol/#:~:text=When%20using%20UDP%20(currently%20an,Proxy%20Protocol%20to%20'on'.

There are some complexities in doing this well for QUIC. It ought to be version-independent (so no using specific long header packet types) and has to handle address migration properly.

martinduke commented 3 years ago

closing this as out of scope for quic-lb.