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

[Brian E Carpenter <[e-mail]>]

On 21/10/2017 14:30, Tom Herbert wrote:
> On Fri, Oct 20, 2017 at 5:42 PM, Brian E Carpenter
> <[e-mail]> wrote:
>>
>> On 21/10/2017 11:13, Tom Herbert wrote:
>>> On Fri, Oct 20, 2017 at 2:41 PM, Brian E Carpenter <
>>> [e-mail]> wrote:
>>>
>>>> On 21/10/2017 09:53, Tom Herbert wrote:
>>>>> On Fri, Oct 20, 2017 at 12:06 PM, Leddy, John <[e-mail]>
>>>>> 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).

Yes. Exactly the point of using the {source, destination, flow_label}
3-tuple in IPv6, but you know that.

>> 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...

Sure, but that means the client end would need to learn the address
from the server end, as part of the first handshake.
 
> In any case, I still don't see a protocol issue with flow labels.

I agree.

> Maybe further discussion on this topic should be on tsvwg list?

I'm not sure where server load balancing really belongs, but it's
a pretty important topic.

    Brian