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

[Gregory Lebovitz <[e-mail]>]

On Wed, Mar 18, 2009 at 5:20 PM, Matthew Ford <[e-mail]> wrote:

> 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.
>

Your second explanation is much more clear, thx. I suggest you provide
something closer to that in your next rev, if one occurs, especially for the
non-english speakers.


>
>
> - 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.
>

This is clearly a subjective matter, so I'll drop it after this last
comment. Agreeing that it's best not to assume too much about users needs in
the future, do we really want to unnecessarily fetter the possible solution
space by the needs of what looks today to be a tiny minority? I think it
might be a LOT easier, and e2e preserving, to solve the mass market problem
first, and then tackle the much more difficult and complex problem of the
tiny minority.


>
>
> - 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.
>

I guess some might look at it that way, but I sure didn't. The changes
needed would be simple "next release" code updates, not "sell more product"
types of changes. But I guess it depends on the message you are trying to
spin as to how you want to represent those changes. Again, it's a subjective
depiction... I won't block on it.

Gregory.

>
>
> Mat
>
> _______________________________________________
> shara mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/shara
>



-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks