[shara] [Fwd: Re: shared-addressing-issues-00 questions]

[Matthew Ford <[e-mail]>]

Late cc

-------- Original Message --------
Subject: Re: shared-addressing-issues-00 questions
Date: Wed, 18 Mar 2009 17:16:24 -0700
From: Matthew Ford <[e-mail]>
To: Gregory Lebovitz <[e-mail]>
References: <[e-mail]>

Gregory,

Thanks for the review. Some responses inline:

Gregory Lebovitz wrote:
> Hey Mat.
> Just read this doc. Thanks for writing it. One question and a few comments
> are below.
> 
> - I fancy myself a decent english speaker, but I couldn't quite make out
> this criteria:
> 
>  1) The proximity of the end user to control over the impact
>            of the solution on the end-to-end communication,
> Would you mind filling that out a bit?

It's a little opaque isn't it? Sorry about that. What I'm saying is that
if there's going to be impacts of these mechanisms on end-to-end (and
there is) then mechanisms that put functions that offer control over
those impacts close to the end user are to be preferred over mechanisms
where control functions are either absent or remote from the end user.
In other words, I don't want to see end users having to make a helpdesk
call to get an inbound port opened up.

> - In 3.1 you say
>    "But for incoming connections, the specific port numbers
>    allocated to customers matter because they are part of external
>    referrals (used by third parties to contact services run by the
>    customers)."
> 
>   then you state:
>     "the distribution is
>    heavy-tailed, so there are typically a small number of subscribers
>    who use a very high number of ports
> [CGN_Viability<http://tools.ietf.org/html/draft-ford-shared-addressing-issues-00#ref-CGN_Viability>
> ]."

Yes, and here we're talking about outgoing ports.

>   and you also state:
>     "Early measurements also seem to indicate that, on average, only very
>    few ports are used by customers for incoming connections.  However, a
>    majority of subscribers accept at least one inbound connection."
> 
>   I would agree that there are very few subscribers who actually need
> inbound connections. More might "accept" inbound connections, but it's not
> clear that these were actually needed/desired. I.e. most of the services
> that 99% of the Internet users/subscribers use are "brokered" through some
> meet-in-the-middle server/service to which they initiate an outgoing
> connection first. If another outside user needs to "contact" the subscriber,
> that contact is most often performed in a transaction through an already
> established 3rd party server/service connection.
>    My point is that perhaps the need for incoming connections is similarly
> heavy-tailed, such that there will typically be a very very small number of
> subscribers running services needing/desiring un-brokered incoming
> connections. And perhaps this number is so few that we could distill the
> problem space into two:  one for 99% of the users, and a separate for the
> 1% desiring un-brokered inbound connections.
>    Thoughts?

I'd rather not make sweeping assumptions about what users want or need
based on (necessarily subjective) observations of today's network. And
I'd even less want to make engineering trade-offs based on those
assumptions.

> - After:
>    "Such an infection
>    could rapidly exhaust the shared resource of the single IPv4 address
>    for all connected subscribers."
>  ADD:
>    "However, the simple inclusion of per-subscriber connection limiting
> would go a long way to mitigate this risk."
> 
>  WHY:  Every customer ISP discussion we've seen on these topics comes with
> "per-user connection limit setting" in the "MUST HAVE" category of
> requirements. I doubt any products proposing to meet these requirements will
> ship without it.

Yup.

> 3.2
>   Again, I think this is a tiny subset of the actual use cases, maybe 1%,
> maybe. ISPs could simply reserve these for users who had purchased the MONDO
> pack, which included service hosting. The rest of our grandmas, kids,
> uncles, and brothers would simply purchase the BASIC pack, with no service
> hosting, and would never get assigned well known ports, because they didn't
> need them.

Again, I don't like these assumptions about what users need and want.
The potential for all Internet users to be service providers is
fundamental to the utility of the network.

> 3.4
>   perhaps change this:
>     "widespread adoption of port-shared addresses
>    by service providers will make these complications considerably more
>    widespread and severe."
>  to this new:
>    "widespread adoption of port-shared addresses
>    by service providers will require a modified operational model in order
> to better record network activity. Such a modified operational modify may
> require networking product modifications to provide operators with IP + Port
> for various logging and monitoring events."
> 
>   WHY: "complications widespread and severe" seems perhaps a bit overstated
> for what is actually needed. I.e. if consensus leads us all to an address
> sharing model, we'll need to make some ops changes in the products to go
> with it. Not the end of the world.

Sell more product, increase opex, pass costs onto end-users. I see two
losers and one winner in this equation.

Mat