Re: draft-phelan-dccp-natencap-02

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

 



Hi Colin,

See inline...

Tom P.

> -----Original Message-----
> From: Colin Perkins [mailto:csp@xxxxxxxxxxxxx]
> Sent: Monday, December 01, 2008 1:43 PM
> To: Phelan, Tom
> Cc: dccp@xxxxxxxx
> Subject: Re:  draft-phelan-dccp-natencap-02
> 
> Tom,
> 
> On 31 Oct 2008, at 17:45, Phelan, Tom wrote:
> > I've submitted draft-phelan-dccp-natencap-02.  You can get the text
> > from
> > http://www.phelan-4.com/dccp/draft-phelan-dccp-natencap-02.txt and a
> > diff-marked version from
> >
http://www.phelan-4.com/dccp/draft-phelan-dccp-natencap-02-diffs.pdf.
> >
> > The main change is to update RTP over DCCP to add SDP to indicate
the
> > type of DCCP encapsulation to use.  Feedback appreciated :-).
> 
> In section 3.6, it states that an application SHOULD NOT register
> different service codes and port for different combinations of
> encapsulation and IP version. Since there is no guidance on when it's
> appropriate to deviate from this advice, may I suggest the text
> should say MUST NOT instead?

[Tom P] Yes, I agree.
> 
> Section 4 hints that the encapsulation of a higher-layer protocol
> with DCCP may differ between DCCP-RAW and DCCP-NAT. That seems
> undesirable to me - is there a use case for this? If not, I suggest
> the text be updated to be "MUST be the same".

[Tom P] I don't know of a use case for this.  I allowed it, with what I
hoped was a high bar for justification, just in case.  I'd support "MUST
be the same".

> 
> Section 5 suggests an SDP attribute to signal the use of DCCP-NAT.
> It's not clear why this is needed. I'd expect the operating system to
> try both native and UDP-encapsulated connections in parallel for the
> DCCP-INIT, and use that which works, rather than applications be
> aware of the encapsulation. Wouldn't any choice be a matter of policy
> for the OS, not the application?

[Tom P] Well, this is an interesting can of worms :-).  I assume that
the application chooses the encap, just like it chooses IP version.  It
would be really nice, IMHO, if the OS chose the IP version, but it
doesn't in anything I know of (the app has to open a PF_INET or PF_INET6
socket).

But there are of course complications involved with the OS choosing
either encap or IP version.  Two packets where only one is necessary.
One first and the other after a delay or back-to-back?  At the server,
answer the first one you see and ignore the later one?  But what about
retransmissions?  And apps will want some control over things -- to
exclude or prefer one or the other for security or efficiency reasons.

So I decided the simpler thing is to make the app choose.  I'll listen
to arguments about why OS chooses is better.

> 
> Cheers,
> --
> Colin Perkins
> http://csperkins.org/
> 
> 



[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