Re: Soliciting input on UDP encapsulation for DCCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A few comments in-line, some of which I raised last time, but don't recall the answers.


Pasi Sarolahti wrote:
Hello,

During the Hiroshima meeting last week some support (and some concerns) was voiced about working on UDP encapsulation for DCCP, with a suggestion to allocate an UDP port to be used for DCCP encapsulation. To make this happen, it was proposed that we bring back draft-phelan-dccp-natencap, for the WG to submit it for Experimental RFC. Tom has now updated the draft and the refreshed version can be found at http://tools.ietf.org/html/draft-phelan-dccp-natencap-03

With the above background in mind, I'm now looking for input on the following questions:

a) in your opinion, should the DCCP WG start working on UDP encapsulation for DCCP?
>
No, or at least unsure.

I'd love to see a tunnel encapsulation, however I'd also like to consider the feasibility of a common method for all transports - or at least one that handles UDP-Lite, SCTP and DCCP consistently with the possibility of later extension. If I were in the DCCP meeting I would have tried to push on this one and see what people said, hence I'd be keen to seen feedback via the list. If there are good reasons to continue separate approaches for each, that would be fine, but I'd expect to see this rationale somewhere in the draft.

b) if yes, do you think draft-phelan-dccp-natencap is a good starting point for this, and therefore should become a WG document?

Maybe, although I would think it is worth considering a straight UDP encapsulation that does not adjust the position and order of the fields.

In addition, please speak up if you have other technical comments about the draft.

Separate email sent to the list.

Thanks!

- Pasi


Finally, I think I'd say it was essential that any encapsulation draft also notes the drawbacks of this mode, and hence advocates native transport were possible!

e.g.
No currently defined support for ECN
No currently defined support for shared PMTUD
Restricted support for partial coverage

- The pros would seem to outweigh the cons, but there are disadvantages.

Gorry

P.S. I also believe this should be discussed at TSVWG, since there is already a proposal for an SCTP encapsulation.


[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux