Re: options or protocols?

------ Original Message ------
From: "Eliot Lear" <lear@cisco.com>
>Adrien,
>
>On 4/4/12 2:03 AM, Adrien W. de Croy wrote:  
>> 
>>The original argument was one about whether it's worth-while 
>>specifying features that are mandatory to implement, but optional to 
>>use.
>> 
>>This pipelining thing was given as an example.
>
>Good point.  I raised this in the WG session in Paris and I'll say it 
>again.  We[*] have an opportunity to consider peeling off different 
>portions of use cases and applying different solutions to them.  That 
>leads to specific optimizations, which is a good thing, and avoids or 
>reduces the options game.  The question for me is whether we can find 
>the right buckets, as it were.  There is one very large bucket, which 
>is non-browser use.
>
>Going against all of this is the argument that use of new ports is a 
>non-starter, in part due to firewall administrator concerns.  I tend 
>to discount this argument – slightly.  That is- if the use has a good 
>enough draw, firewall administrators would, I think on the whole, come 
>around.  More-so when the alternative is losing visibility due to 
>everything being encrypted in payload.
  
There are a bunch of issues related to either keeping the same port or 
choosing another.
  
One argument is that getting a new port opened on a firewall can take a 
long time, due to various issues.  One of these issues is ability to 
control.  However, until firewall software is updated, it won't be able 
to control upgraded traffic over port 80 anyway, except for maybe 
breaking the upgrade mechanism.
  
In fact I think there will be a bunch of intermediaries (mainly CPE) 
that will break the upgrade.  I know earlier versions of WinGate didn't 
strip headers matching Connection tokens, so would pass the Upgrade 
through, and the 101 back, but barf on the new protocol.
  
I also suspect there is a plethora of cheap DSL/NAT routers which do 
port 80 inspection which may break.  Whether they break in a way that 
prevents operation or not is another matter.
  
I also don't know of any cheap DSL/NAT that wouldn't just allow port 
(say) 100 out with no trouble.
  
Using another port will also bypass issues with ISP intercepting 
proxies.. until they are upgraded to actually handle the new protocol.
  
One issue would be trying to figure out which port to make a connection 
attempt on.  Could use a IPv6 approach.  Try connecting to both at 
once, and whichever returns a SYN-ACK first you use that one.  Coupled 
with attempts to prefer IPv6 this would result in 4 simultaneous 
connection attempts though, and in fact most sites running servers 
would probably be running on both ports, so you may still need a way to 
favour port (say) 100.
  
In that way, using port 443 with TLS was a smart move, since it allowed 
negotiation below HTTP using NPN, so it became a non-issue.  The only 
similar approach in TCP would be maybe a NPN-like mechanism as a TCP 
option, which I think would be relatively poorly supported in stacks.  
That's what the port number was intended to do.

Adrien
>
>
>Eliot
>
>[*] Who is this “we”, anyway?  That in itself is worthy of discussion.