Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]

On Fri, Oct 20, 2017 at 5:42 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>
> On 21/10/2017 11:13, Tom Herbert wrote:
> > On Fri, Oct 20, 2017 at 2:41 PM, Brian E Carpenter <
> > brian.e.carpenter@gmail.com> wrote:
> >
> >> On 21/10/2017 09:53, Tom Herbert wrote:
> >>> On Fri, Oct 20, 2017 at 12:06 PM, Leddy, John <John_Leddy@comcast.com>
> >>> wrote:
> >>>
> >>>> In order packet delivery requirements considered harmful to the
> >> Internet…
> >>>>
> >>>>
> >>>>
> >>>> I’m assuming random per packet flow label assignments are within spec as
> >>>> long as they are set by the source.
> >>>>
> >>>>
> >>>>
> >>>
> >>> Yes, there is no requirement that the flow label be persistent at all in
> >> a
> >>> flow.
> >>
> >> http://mailman.postel.org/mailman/listinfo/internet-history says:
> >>
> >>    To enable Flow-Label-based classification, source nodes SHOULD assign
> >>    each unrelated transport connection and application data stream to a
> >>    new flow.  A typical definition of a flow for this purpose is any set
> >>    of packets carrying the same 5-tuple {dest addr, source addr,
> >>    protocol, dest port, source port}.  It should be noted that a source
> >>    node always has convenient and efficient access to this 5-tuple,
> >>    which is not always the case for nodes that subsequently forward the
> >>    packet.
> >>
> >> So, technically it's a recommendation, not a requirement. But for load
> >> balancing or ECMP to actually work, it's a requirement.
> >>
> >
> > Brian,
> >
> > I don't think that says anything that the flow label has to be persistent
> > for the life of the connection. It is incorrect, though, if any nodes
> > assume that the flow label is persistent. The soft state approach like in
> > this QoS draft doesn't require the flow label to be persistent.
> >
> > Load balancing only fails when the destination address is being treated as
> > an anycast and the address is being used as an endpoint of connections that
> > are on different hosts. But such stateful load balancing becomes obsolete
> > as the externally visible flow information is decoupled from the end-to-end
> > identification of the flow like happens in QUIC, ESP, etc.
>
> That's not really true for server load balancing. Delivering all packets
> in the flow to the same *instance* of the host is essential to be
> able to complete transactions. Whoever unwraps the flow identification
> has to be able to select the required server instance, at line speed.

Brian,

The 5-tuple hashing for forwarding to VIPs only works to the extent
that the 5-tuple hash identifies the transport flow and is readily
visible. That may be true for plain TCP, but not necessarily other
protocols. For instance, in QUIC the end points identify a connection
by a connection ID that is separate from the 5-tuple. One of the goals
is to be resilient to NAT so that even if the 5-tuple changes, like
when the source address or port changes because NAT evicted a UDP
binding, the QUIC connection is still viable
(draft-ietf-quic-transport-07). So a load balancer just looking at UDP
5-tuples won't work for QUIC. There's a similar issue with MPTCP in
that all of the sub-flows have different hashes but need to be
delivered to the same server instance
(draft-duchene-mptcp-load-balancing-00).

>
> https://tools.ietf.org/html/rfc7098 sort of hints at this and we
> tried to go further in
> https://tools.ietf.org/html/draft-tarreau-extend-flow-label-balancing
> but that faded away. And there's
> https://tools.ietf.org/html/draft-wang-v6ops-flow-label-refelction
>
> Nothing seems to quite work.
>
For IPv6, I am wondering if each server instance could just be given a
few million unique addresses and then replace load balancers with
simple routing...

In any case, I still don't see a protocol issue with flow labels.
Maybe further discussion on this topic should be on tsvwg list?

Tom