Opened 7 years ago

Last modified 7 years ago

#31 new defect

Ron Bonica's queries on rest-of-path, applicability, deployment & attacks

Reported by: rbriscoe@… Owned by: bob.briscoe@…
Priority: major Milestone:
Component: concepts-uses Version:
Severity: Submitted WG Document Keywords:
Cc:

Description


DISCUSS: --------------------------------------------------------------------

This may be a DISCUSS-DISCUSS, but I would like to pose the following questions:

1) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs downstream?. For example, assume that my ISP deploys CONEX. Assume also that a loss-prone link connects my PC to the CPE router in my kitchen. The TCP stack on my PC will report lots of loss. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network?

2) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs upstream? For example, assume that my ISP deploys CONEX. Assume also that I subscribe to a stream that incurs loss before it hits my ISPs network. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network?

3) Is the applicability of CONEX restricted to access networks, where it is possible to deploy per-user policers at the distant end of the network from the user?

4) Can CONEX markings be used as an attack vector?

5) How will CONEX behave in networks where incoming traffic can be characterized as follows: 90% is streaming UDP over IP multicast 10% is TCP.

In this example, assume that multicast traffic is responsible for 90% of the congestion and that the multicast receivers send traffic in the reverse direction very infrequently.

6) How will CONEX work in a transition scenario, when some transport layer stacks are CONEX aware and others are not.

7) Does CONEX encourage traffic originators to falsify congestion markings?


In Section 3.1, please be specific about the policer counting IP-Layer-ConEx?-Signals, and not Congestion-Feedback-Signals

Change History (1)

comment:1 Changed 7 years ago by rbriscoe@…

Q1) & Q2) Can we distinguish rest-of-path congestion (two questions cover traffic in & out relative to domestic access user)?

"2.3 Rest of Path Congestion" explained much more fully, esp. dependence on ECN
"6 Experimental Considerations" recommends that experiments test whether approx rest-of-path is sufficient in the proposed scenarios, given likely lack of ECN.

Q3) ConEx? for access net only?

"5. Deployment Arrangements" now refers to more varied deployment scenarios for ConEx?, e.g. within the data centre. And access scenarios (fixed & mobile) also include ConEx? at the 'Content' end.

Q4) ConEx? as an attack vector?

This doc is not about mechanism, so it points to conex-abstract-mech for all security discussion. It wouldn't be appropriate to identify potential types of security attack and their defences in this doc, but I raised this as a ticket against abstract-mech.

Q5) ConEx? & multicast

conex-abstract-mech now explains why whole-path congestion (and therefore ConEx?) is not applicable with multicast. But this requires too much mechanism detail for the present doc, which is about why, not how.

Q6) ConEx? in a transition scenario.

"5. Deployment Arrangements" now includes a para on this, then refers to conex-abstract-mech where there's lots more detail on incremental deployment.

Q7) ConEx? originator encouraged to falsify?

"7. Security Considerations" refers to conex-abstract-mech for all security issues. A large part of abstract-mech is concerned with this specific question (termed audit).

Note: See TracTickets for help on using tickets.