Layered Encapsulation of Congestion Notification draftbriscoetsvwgecntunnel01'txt

1
Layered Encapsulation of Congestion
Notificationdraft-briscoe-tsvwg-ecn-tunnel-01.txt

• Bob Briscoe, BTIETF-73 pcn Nov 2008

2
status

• Layered Encapsulation of Congestion Notification
• new WG draft draft-ietf-tsvwg-ecn-tunnel-01.txt
  as of late Oct'07
• previously draft-briscoe-tsvwg-ecn-tunnel-01.txt
  
• intended status standards track
• RFC pub target ? TBA
• immediate intent discuss including fix to decap
  as well as encap get people to sign up to
  review
• w-gs r-gs affected TSVWG, PCN, ICCRG, IPsec,
  Internet Area?

3
reminder (exec summary)

• scope
• solely wire protocol processing of tunnelled ECN,
  not marking or response algorithms
• sequence of standards actions led to perverse
  position
• non-IPsec ECN tunnels RFC3168 have vestige of
  stronger security than even IPsec RFC4301
  decided was necessary!
• limits usefulness of 3168 tunnels
• e.g. PCN "excess rate marking" works with 4301
  but not 3168 tunnels
• bring ECN IP in IP tunnel ingress RFC3168 into
  line with IPsec RFC4301
• all tunnels can behave the same, revealing full
  congestion info
• anyway, copying of whole ECN field is simpler
• thorough analysis of implications
• security, control, management
• guidance on specifying ECN behaviour for new
  links, for alternate PHBs
• ideally fix egress too (currently only 'for
  discussion')

4
reminder (exec summary)
E
I
encapsulation at tunnel ingress
decapsulation at tunnel egress
I
5
text updates since IETF-72draft-briscoe-tsvwg-ec
n-tunnel-01.txt ? draft-ietf-tsvwg-ecn-tunnel
-00.txt ? draft-ietf-tsvwg-ecn-tunnel-01.txt

• much simpler method to monitor tunnel's
  contribution to congestion
• see spare slide or Appendix B
• all significant edits concern decap encap has
  stayed stable
• documented full set of illegal combinations of
  inner outer at egress
• on which egress should (optionally) raise a
  management alarm
• generalise egress behaviour while we're at it?
• currently just in appendix 'for discussion'
  says 'not normative'
• problem current egress behaviour discards
  changes to ECT(0) or ECT(1)
• space for 2 congestion levels (e.g. PCN) but
  can't use it
• effectively wastes half a bit of the IP header
• now written up pros cons of change (Appx C)
• convinced myself this change should be in
  normative part of draft
• what do you think...?

6
current egress behaviour
E
I
encapsulation at tunnel ingress
decapsulation at tunnel egress
E

• OK for current ECN
• but any changes to ECT lost
• effectively wastes ½ bit in IP header
• again for safety against marginal threat that
  IPsec decided was manageable
• PCN tried to use ECT(0/1)
• but having to waste DSCPs instead
• or a limited scheme where it's arranged for the
  egress to already know which of ECT(0/1) the
  ingress originally sent

(!!!) illegal combination, egress MAY raise an
alarm
7
'comprehensive' egress rules (only 'for
discussion')
E
I
encapsulation at tunnel ingress
decapsulation at tunnel egress
E

• recall proposed change to ingress
• brings RFC3168 into line with RFC4301
• if we also changed the egress
• it would be a new update to both RFCs
• but no effect on any existing tunnels
• adds a new capability using a previously illegal
  combination of inner outer
• only tunnels that need the new capabilitywould
  need to comply
• and update, not a fork
• note well change to egress is currently not in
  the normative part of this proposal
• but documented in appendix C 'for discussion'
• however I'll make it normative if no-one objects

(!!!) illegal combination, egress MAY raise an
alarm
8
new comprehensive decap rulespros cons of ways
to introduce them
9
next steps

• should we change the egress at the same time?
• tunnel stuff makes people's heads hurt
• needs careful list discussion
• remember, these are nuances to the behaviour of
  the neck of the hour-glass
• will need to assure IPsec folks that they don't
  have to change (again)
• I'll only make comprehensive egress rules
  normative if consensus to do so
• I'll also add reasoning for original egress
  behaviour (requested in Anil Agarwal's rvw)
• plan to split out guidelines for new ECN
  encapsulations
• for those adding congestion notification to
  alternate PHBs or to layer 2 technologies (incl.
  non-IETF, e.g. IEEE 802.1)
• better in a separate (informational) I-D just
  stds track IPinIP stuff in this one
• and improve structure of this draft at same time
  (Michael Menth's comments)
• need people to sign up to review this draft
• will need reviews once all the above settled

10
Layered Encapsulation of Congestion
Notificationdraft-briscoe-tsvwg-ecn-tunnel-01.txt

• QA

11
contribution to congestion across tunnel
42 marked
30 marked
42 marked
encapsulation at tunnel ingress
decapsulation at tunnel egress

• complaint
• if CE copied at ingress, operators can't
  distinguish congestion added since tunnel ingress
• it's not 12
• new method in Appendix B
• it's 12/(100-30)
• ? 17
• just monitor the 70 packets without the inner
  header marked

The large square represents 100 packets
30
ECN markingacross tunnel
problem tunnel marks some packetsthat were
already marked
pt
12
0
30
100
inner header ECN marking(already marked before
ingress)
12
backward forward compatibility
C calculation C (more severe multi-level
markings prevail) B calculation B (preserves CE
from outer) A calculation A (for when ECN field
was 2 separate bits) inner forwards inner
header, discarding outer n/a not allowed by
configuration