Subject: Re: [conex] FW: comments on draft-briscoe-conex-initial-deploy

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 Nov 2011 13:07:41 +0000

Phil,

[I didn't get the first email. Don't know what happened there, cos 
I'm registered with my bt.com address for this draft, not jungle. Did 
you get a bounce message?]

Thanks for this - very useful (as your reviews always are). Responses inline.

At 09:14 09/11/2011, [email-masked] wrote:
>In case email distorts, here is the pic

It was OK in email, but useful to see how different ASCII editors and 
email display the same ASCII differently! I'm not entirely happy with 
either diag, but yours gives me food for thought - I'll ruminate on it.

>- also the paper which ruminated on the isp runs cdn & nw scenario. 
>Not sure i completely believe it, but might be useful text?

I will refer to this paper as an alternative scenario. I find this 
scenario less believable, because the benefit is small and the effort 
large. In the I-D I'm trying to show that there is a ConEx deployment 
path with clear benefits for all.

More...

>phil
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of [email-masked]
>Sent: 09 November 2011 09:12
>To: [email-masked]
>Subject: [conex] comments on draft-briscoe-conex-initial-deploy
>
>http://tools.ietf.org/id/draft-briscoe-conex-initial-deploy-00.txt
>
>
>Bob,
>thanks for the draft, think it's important to have started this. 
>some comments.
>
>I think you could start at S4. the earlier sections stop the reader 
>getting rapidly to the main bit of the doc.

My judgement is that only a very few people have ConEx sufficiently 
in their head not to need a recap.

I will move 3.2 to later (or delete it).

However, I would rather put a note at the end of the Intro saying 
that a page of recap bullets follows, and the reader can jump to the 
meat if they don't need recap. Then I would keep the page of 
abstract-mech recap where it is (currently sections 2 & 3.1).

>You start by saying that the initial step is a ledbat source is 
>conex enabled; the second step is the network becomes conex-enabled. 
>personally i wouldn't call this "unilateral deploymet by a single 
>network" (scope of draft in S1). Talk of this ledbat-conex source 
>somewhat disappears later on. if this is the deployment path, it 
>also raises the question of what's the deployment incentive for 
>ledbat, is this clear-cut?

True. I should expand the para about incentives to deploy ConEx for 
end-hosts at the end of the first para of S.4 (before any of the 
use-cases 4.1-4.3).

There is more to say about this:
- Examples of other cases where end-hosts have deployed a protocol 
speculatively, in the expectation the network will deploy something 
in response (e.g. uTP).
- The protocol must have near-zero probability of causing negative 
side-effects (e.g. getting snarled in certain middleboxes). Even a v 
low probability will tip the scales against speculative deployment.
- Some of the later scenarios involve a more co-ordinated deployment 
on end-hosts and network (e.g. mobile and data centre).

S.4.1.2 talks about operator incentives to deploy. I wanted to say 
what it is that an operator deploys before talking about incentives 
to deploy it.

However, you're right that readers need motivation before detail, 
rather than the other way round. I'll rethink.

>I attempted to re-draw figure 1, see below, see if you think it's clearer.
>
>I think it would be clearer if the conex-ISP just ran the network - 
>dividing into core and access seems unnecessary detail [at least 
>until the basic deployment scenario is clear]

The reason for the division is not to do with ownership, but to do 
with where congestion is most likely. I don't know whether you got 
down to my detailed description, but the BRAS encapsulates congestion 
in multiple places. This makes audit feasible without needing ECN deployment.

This is why the diag must have the BRAS on it IMO.

I need to say that the incentive for one network to deploy is:
a) to be able to coordinate its response to all the different inputs 
when there is no single place where all incoming traffic passes 
through. ConEx gives the network info to be able to do distributed 
traffic management without tromboning all traffic through one box.
b) to encourage scavenger behaviour

>I think the initial deployment step is where the ISP runs the 
>network & a data centre - the DC has conex-enabled conex sources 
>(which are trusted about their conex markings, since they're under 
>ISP's control).

Isn't that a pointless scenario? What is the beneficial effect of 
deploying ConEx that couldn't be achieved with trust anyway?

I'd rather stick with the scavenger motivation and mention your 
scenario as an alternative and cite your paper for details.

>you need to mention how other traffic is handled.

S.4.1.2 covers this. I agree it could be mentioned earlier then 
referred forward to S4.1.2.

>a step beyond the initial one is where other senders are 
>conex-enabled, but not trusted (i wouldn't include them on fig 1) - 
>only at that stage might ledbat become relevant.

As above, isn't it pointless before scavenger becomes relevant? What 
was the beneficial effect before scavenger?

>I think the scenario is that the DC-ISP offers a premium service to 
>content providers, which internally it implements using conex.

You're wanting to write a different scenario. Why would a network use 
a new protocol (ConEx) in order to do something it can do with an 
existing one (Diffserv)? Or am I misunderstanding what you mean by premium?

>anyway, i think the WG should decide whether the initial deployment 
>case is via ledbat or a conex-core also running a DC. or via mobile 
>network or internal to data centre.

Certainly. I'll get Andrea to ask that in the presentation on Thu. 
And I'll ask in a focused posting to the ML.

However, the charter already says we have to focus on the receiving 
network scenario (whatever that means). Mobile and data centre are 
brought in, because they are other believable scenarios.

Thank you again.

Bob

>thanks,
>phil
>
>----
>                       <----     Single ISP operates    ---->
>                        data centre & core & access networks
>                                all are ConEx-enabled
>
>                                       _________      _______      ____
>                                      | CORE    |    |ACCESS |    |HOME|
>                                      | NETWORK      |NETWORK|    |NET |
>                        _________     |         |    |       |    |    |
>                       | ISP's   |    |         |    |       |    |    |
>                       | data    |    |         |    |       |    |    |
>                       | centre  |    |         |    |       |    |    |
>                       |         |    |         |    |       |    |    |
>                       | +-------+    +-------+ |    |       |    |    |
>                       | |trusted|    | ConEx | |    |       |    |    |
>                       | | ConEx | => |       | |    |       |    |    |
>                       | |sender |    |monitor| | => |       | => |    |
>                       | +-------+    +-------+ |    |       |    |    |
>                       |         |    |         |    |       |    |    |
>                       |_________|    |         |    |       |    |    |
>  _________                           |         |    |       |    |    |
>| ConEx-  |     ___                  |         |    |       |    |    |
>|enabled  |    |   |                 | CORE    |    |ACCESS |    |HOME|
>| CDN     |    |   |                 | NETWORK |    |NETWORK|    |NET |
>|         |    | I |                 |         |    |       |    |    |
>| +-------+    |   |                 |         |    |       |    |    |
>| | Non-  |    | N |                 +-------+ |    |       |    |    |
>| |trusted|    |   |                 | Non-  | |    |       |    |    |
>| | ConEx | => |==>| ==============> | ConEx | | => |       | => |    |
>| |sender |    |   |                 |policer| |    |       |    |    |
>| +-------+    | T |                 +-------+ |    |       |    |    |
>|_________|    |   |                 |         |    |       |    |    |
>                | E |                 |         |    |       |    |    |
>                |   |                 |         |    |       |    |    |
>  _________     | R |                 |         |    |       |    |    |
>|'legacy' |    |   |                 |         |    |       |    |    |
>|         |    | N |                 |         |    |       |    |    |
>| +-------+    |   |                 +-------+ |    +-----+ |    |    |
>| | Non-  |    | E |                 | ConEx | |    |ConEx| |    |    |
>| | ConEx | => |==>| ==============> |       | | => |     | | => |    |
>| |sender |    |   |                 |policer| |    |audit| |    |    |
>| +-------+    | T |                 +-------+ |    +-----+ |    |    |
>|         |    |   |                 |         |    |       |    |    |
>|_________|    |___|                 |         |    |       |    |    |
>                                      |         |    |       |    |    |
>                                      |_________|    |_______|    |____|
>
>
>
>
>Philip Eardley
>Research and Technology Strategy
>
>This email contains BT information, which may be privileged or 
>confidential. It's meant only for the individual(s) or entity named 
>above. If you're not the intended recipient, note that disclosing, 
>copying, distributing or using this information is prohibited. If 
>you've received this email in error, please let me know immediately 
>on the email address above. Thank you. We monitor our email system, 
>and may record your emails.
>British Telecommunications plc
>Registered office: 81 Newgate Street London EC1A 7AJ
>Registered in England no: 1800000
>_______________________________________________
>conex mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/conex
>
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design