Re: [tae] New draft: announcing the supported transports via DNS

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Bryan Ford [mailto:[e-mail]] 
> Sent: Friday, September 18, 2009 1:58 PM
> To: Caitlin Bestler
> Cc: Dan Wing; [e-mail]; 'Joe Touch'
> Subject: Re: [tae] New draft: announcing the supported 
> transports via DNS
> 
> On Sep 18, 2009, at 3:19 PM, Caitlin Bestler wrote:
> > On Sep 18, 2009, at 12:07 PM, Dan Wing wrote:
> >
> >> Can you enumerate those requirements, or shall we just 
> throw things  
> >> at the
> >> wall?  This goes back to Caitlin's post
> >> <http://www.ietf.org/mail-archive/web/tae/current/msg00114.html>  
> >> which
> >> suggested we take a step back and look at what we want.  I'm all  
> >> for doing
> >> that.  This list has been too quiet, so we wrote a straw man.  I  
> >> take it you
> >> don't like the straw man because it's trying to cover the DNS use- 
> >> case, and
> >> your use-case is IP address literals, and your use-case can incur  
> >> additional
> >> round trip(s) to learn which transport protocols the 
> server supports.
> >
> > Any non-directory based solution is going to run the risk 
> of having  
> > an extra
> > message required to setup the connection/association. That 
> suggests  
> > to me
> > that the solution set should include a directory based method, I'm  
> > just not sure
> > that DNS is appropriate for service-specific information.
> 
> Directory-based solutions - or "out-of-band" solutions in general -  
> don't eliminate that risk, because as Dan just pointed out, in-band  
> probes are necessary anyway because a middlebox might (read: usually  
> will, on the IPv4 Internet) block the use of a new transport even if  
> the remote endpoint (truthfully) declares that it is supported.  Out- 
> of-band communication simply cannot reliably provide the information  
> that is really needed on the Internet as it exists: out-of-band  
> information can at best serve as hints at which alternatives to try  
> (or to try first).
> 
> Further, although the extra message is probably unavoidable 
> in certain  
> scenarios, in others it could potentially avoided with a bit of  
> cooperation between the alternative transport protocols and the  
> negotiation mechanism.  That was the basic gist of the paper I  
> mentioned earlier on this list, which will appear (probably in  
> slightly revised form) in this year's HotNets:
> 
> 	"An Efficient Cross-Layer Negotiation Protocol"
> 	http://bford.info/pub/net/nego.pdf
> 
> Finally, one more point in favor of in-band over out-of-band 
> solution  
> is that you only need _one_ in-band solution,

No, you need two:  one for UDP upgraded to some-UDP-replacement,
and another for TCP upgraded to some-TCP-replacement.

I have seen ideas on this mailing list for how to do in-band with TCP (using
TCP options).  I haven't seen any ideas for how to do in-band with UDP;
perhaps because nobody cares about evolving UDP, or perhaps because there
isn't an in-band solution for UDP (I expect it's the latter).

-d


> whereas with 
> out-of-band  
> solutions you need to define one for each directory protocol 
> you care  
> about (maybe only DNS, but that's one), PLUS a separate one for each  
> other protocol that exchanges IP addresses for the purpose of 
> setting  
> up transport connections (e.g., SIP, FTP, ???).  Do we really 
> want to  
> have to define and deploy N different negotiation extensions, 
> one for  
> each protocol that produces IP addresses in one way or another?
> 
> > I think the following objectives need to be met for any 
> probe-based  
> > solution:
> >
> > 1) Must add no additional messages when the default protocol is  
> > selected.
> > 2) TCP must be a valid default protocol.
> > 3) There may be a case for adding UDP to that set for RTTP.
> > 4) It should be capable of learning when a given 
> client/server pair  
> > is blocked
> >    from using Transport X by some middle-box. Note: this is  
> > something a
> >    directory-based solution probably cannot do.,
> 
> Yes, these seem reasonable to me, except generalize 2 and 3 with  
> something to the effect of:
> 
> 	When negotiating a transport for a given application X, 
> whatever  
> transport is normally the basic, "must-support" transport for  
> application X must be a valid default transport protocol.
> 
> That means TCP must be a valid default protocol when negotiating a  
> transport for HTTP; UDP must be a valid default protocol when  
> negotiating a transport for RTTP; etc.
> 
> Bryan
>