[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: flow label demultiplexing
El 18/04/2005, a las 18:23, Iljitsch van Beijnum escribió:
This is a good point, and I don't recall seeing it in the draft.
However, I would be interested in hearing if you have ideas what the
protocol should do after narrowing the flow label down to 3 or 4.
How does it disambiguate further from those 3 or 4? Would you rely
on the implementation taking a peek at (say) layer 4 headers or some
There are two obvious options:
1. The flow label is relevant regardless of the addresses: this can't
work because of the possibility of clashes with flow labels in
2. The flow label is only relevant with certain source/dest address
combinations: but what's the additional benefit of the flow label
here, we can demultiplex on the addresses
Well, there could packets with the same src and dst address, that
belong to different communications with different ULIDs, right? the
flow label is to determine the proper demux context.
I guess the only way the flow label could be useful is as a last
resort to correlate packets with unknown addresses to existing
sessions. But this is insecure, so we need to trigger some kind of
negotiation to get to know the unknown addresses. This could still be
somewhat useful because if we're 99% sure who we're talking to we can
do a one RTT challenge/response rather than something more involved.
Or maybe I'm just going down the wrong path here... Why do we need a
bit in the IP header again?