Colin,
The problem solved by the 6-tuple is that the receiver CANNOT simply throw
away the UDP ports. The UDP ports are a critical component of flow
demultiplexing. Do I misunderstand you?
Eddie
On 2/7/11 3:54 AM, Colin Perkins wrote:
On 1 Feb 2011, at 09:02, Pasi Sarolahti wrote:
On Jan 19, 2011, at 9:40 PM, Gorry Fairhurst wrote:
I have now implemented all the corrections in the UDP encaps draft, except for the issue of how we implement transport demultiplexing, where there seems to be multiple ideas. We clearly need to choose either
the 4-tuple demux or the 6-tuple demux.
Indeed. I think there are three choices
* 6-tuple
* 4-tuple IP/UDP (with checks against conflicting DCCP connections)
* 4-tuple IP/DCCP (with checks against conflicting UDP ports at UDP decapsulation point)
There have been arguments suspecting kernel implementation feasibility of 6-tuple. People have also wanted to see UDP tunneling work with unmodified DCCP implementation. If I understand correctly this would be difficult with the first two option. Would there be something wrong with the last option?
I think this is the only remaining open issue (right?). So let's try to reach a conclusion. If you don't have clear favorite, is some of the options out of question?
My preference is for the 6-tuple, since this is conceptually simplest: the receiver operation is just to remove the UDP header, and treat the encapsulated DCCP packet as any other native DCCP packet received. I'd expect this also to be simple to implement as a user-space daemon.
