Re: [multipathtcp] Draft Multipath TCP (MPTCP) BOF description

On May 9, 2009, at 6:38 PM, Salvatore Loreto wrote:
> Preethi Natarajan wrote:
>>> -----Original Message-----
>>> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent:  
>>> Friday, May 08, 2009 1:09 PM
>>> To: Preethi Natarajan
>>> Cc: 'Arnaud Ongenae'; multipathtcp@ietf.org
>>> Subject: Re: [multipathtcp] Draft Multipath TCP (MPTCP) BOF  
>>> description
>>>
>>> Suppose that a browser wants to load pages from a website. How  
>>> does the browser know if the server also supports SCTP? For IPv4  
>>> vs IPv6 we could solve this using the DNS, but for TCP vs SCTP  
>>> this is harder.
>>>
>>>
>>
>> DNS has been proposed to identify transport protocols in the past,  
>> for ex.
>> see RFC 3263. From what I hear, SRV records have worked quite well  
>> for SIP.
>>
> actually there is already an interesting proposal, take a look at  
> those drafts:
> http://www.ietf.org/internet-drafts/draft-wood-tae-specifying-uri-transports-05.txt
> http://www.ietf.org/internet-drafts/draft-jennings-http-srv-05.txt

Proposals like these are trying to take URIs in exactly the wrong  
direction, IMO, by trying to encode _more_ fragile information about  
"how exactly to access some object", rather than less as they should  
(i.e., what URNs try to do).  When someone gives you a URI or posts it  
on their web page, what you generally want is for your web (or SIP or  
bittorrent...) client to use that as the minimal information necessary  
to find and contact the desired service or object, and then negotiate  
online what specific suite of communication protocols and optional  
protocol features should be used for continuing communication.  That  
way the URI works when either the client or the server don't support  
some alternative transport or other protocol variation (i.e., they can  
fall back on a more basic protocol), in addition to when they do.   
When you encode a requirement to use a particular transport or  
protocol suite into the URI, the URI won't work at all unless both  
parties fully understand the indicated protocol suite.

There may be legitimate corner case uses of such mechanisms to encode  
protocol suites and options and such into URIs, but I haven't yet seen  
any convincing ones.  As far as I can tell the right and only solution  
to the general problem is to come up with a better way to negotiate  
protocol suites and features dynamically.

Bryan

>
> /Sal
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp