Subject: [Capwap] Issue 253: Handling of multiple priority streams over DTLS in datapath.

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Fri, 23 Mar 2007 02:47:12 -0600

This issue discussed in ad-hoc briefly and deferred for further
discussions on list (for want of time) was posted early in feb (see
attached).

This issue has been filed in the tracker a few days ago - to record this
problem. The person who raised the issue earlier in the list and prior
sessions has not responded so far on the email thread (referred to the
attached email for the thread).

There has been one response to, at the best, make it optional.

The WG should decide whether it needs (formal text in the protocol
draft) to address this issue. It has been marked as a bug now. If the WG
does not believe the problem is serious enough to be addressed (for
reasons of deployment model or other) - then the issue will be deferred.

If WG believes the problem needs to be addressed - we welcome a proposal
(253 suggests one approach) and text to go with it.

Please respond to this within the next 2 weeks.

Thanks,

-mani

Subject: [Capwap] <Interim>: Issue ???: QoS-DTLS interaction
From: "Mani, Mahalingam \(Mani\)" <[email-masked]>
To: "capwap" <[email-masked]>
Date: Sun, 4 Feb 2007 22:03:54 -0600

The following was discussed:

*          When data traffic is DTLS-protected between WTP & AC - the different QoS-flows (11e-marked to-DS and Diffserv-marked from-DS) will need to carry appropriate markings. This can lead to spurious replay as the markings may cause reordering along the way - being carried over the same DTLS session.

-         This is a concern for WTP-terminated 802.11i (as above).

-         Is there a need to differentiate control messages?

*          Are there any control messages requiring expedited delivery?

*          Proposed approach

-         Entertain per-DSCP DTLS sessions

-         Use DTLS-session resumption to create DTLS-session per-flow

*          Session-resumption preserves existing DTLS sessions - hence allowing multiple DTLS sessions to exist between the same 5tuple defining the transport endpoint-pair (AC & WTP).

*          Multiple DTLS sessions between the the same WTP-AC pair (5-tuple)

*          Identify and map sessions by hosting DSCP values in the preamble.

-         Nominal DoS concern (generic to all fields in the preamble)

*          WTP-initiated; need a control message to bind sessionID to DSCP.

-         Issue

*          Does DTLS module implementation support multiple sessions for same 5-tuple?

*          How do we let the DTLS module know which SA to pick?

*          Alternatives

-         Use different source addresses to distinguish DTLS sessions

-         Don't mark the encapsulation

Resolution:

This discussion was not closed due to lack of time. No issues have been filed on the tracker yet.

The following is the proposed header addition (QoS Index) to the preamble.
The QI is used to index into the database that maps the DTLS sessionID corresponding to the
QoS value.
 
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

________________________________________________________________________

|  ver(4)  |  QI (3) |                                                                                               |     |

|_______|______|______________________________________________________|___|

It has been argued that since WLAN entertains only 8 categories (802.1p and 802.11e) that the 3-bit index is sufficient.

This mapping in the DTLS-protected datapath will require a control-plane message exchange to map the (AC-WTP)

Address-protocol-port 5-tuple to the sessionid.

The proposal needs to be fully fleshed out with required text (including corner cases when sessions are resumed for recovery purposes).

Thoughts?

Regards,

-mani

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 26 Mar 2007 13:31:59 -0700

This is the known issue (bug) with the protocol. There are 3 options we
have:
 
(a) Do nothing
 
(b) Do nothing but add a statement that "All CAPWAP Control packets go
with the same priority". Same for CAPWAP Data (when using DTLS)
 
(c) Fix the problem
 
I do not think that (a) is an option as the protocol is broken (and I am
not sure how this will pass IESG muster).
(b) is a potential option though it has undesirable side-effects of
serializing everything.
 
The right thing to do will be (c), though I could be convinced to go
with (b). I do not think that (a) is a realistic option.
 
Thanks.
 
-Puneet

________________________________

From: Mani, Mahalingam (Mani) [mailto:[email-masked]] 
Sent: Friday, March 23, 2007 1:47 AM
To: capwap
Subject: [Capwap] Issue 253: Handling of multiple priority streams over
DTLS in datapath.

Thanks,

-mani

---

From: "Sudhanshu" <[email-masked]>
Date: Tue, 27 Mar 2007 15:24:42 -0700

For control path, option b is OK.

For data path, I don't think option a and b are the right approach. 

We should consider for the multiple DTLS session approach using multiple IP
addresses. And we need to come up with signaling mechanism to 

*	Multiple IP addresses for WTP
*	Signal multiple class/TID supported 
*	Mapping of Class of service/TID to multiple DTLS session
*	Above scheme should be optional so that m number of class of service
can be mapped to n number of DTLS sessions, where m >= n

_Suds

  _____  

From: Puneet Agarwal [mailto:[email-masked]] 
Sent: Monday, March 26, 2007 1:32 PM
To: Mani, Mahalingam (Mani); capwap
Subject: Re: [Capwap] Issue 253: Handling of multiple priority streams over
DTLS in datapath.

(a) Do nothing

(b) Do nothing but add a statement that "All CAPWAP Control packets go with
the same priority". Same for CAPWAP Data (when using DTLS)

(c) Fix the problem

I do not think that (a) is an option as the protocol is broken (and I am not
sure how this will pass IESG muster).

The right thing to do will be (c), though I could be convinced to go with
(b). I do not think that (a) is a realistic option.

Thanks.

-Puneet

  _____  

From: Mani, Mahalingam (Mani) [mailto:[email-masked]] 
Sent: Friday, March 23, 2007 1:47 AM
To: capwap
Subject: [Capwap] Issue 253: Handling of multiple priority streams over DTLS
in datapath.

This issue discussed in ad-hoc briefly and deferred for further discussions
on list (for want of time) was posted early in feb (see attached).

The WG should decide whether it needs (formal text in the protocol draft) to
address this issue. It has been marked as a bug now. If the WG does not
believe the problem is serious enough to be addressed (for reasons of
deployment model or other) - then the issue will be deferred.

Thanks,

-mani

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 27 Mar 2007 20:01:11 -0700

I'm ok with (b), but would prefer a statement that the IETF is looking
for field experience on the protocol before addressing the problem. This
could be addressed in the draft standard.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

	From: Puneet Agarwal [mailto:[email-masked]] 
	Sent: Monday, March 26, 2007 1:32 PM
	To: Mani, Mahalingam (Mani); capwap
	Subject: Re: [Capwap] Issue 253: Handling of multiple priority
streams over DTLS in datapath.

	This is the known issue (bug) with the protocol. There are 3
options we have:
	 
	(a) Do nothing
	 
	(b) Do nothing but add a statement that "All CAPWAP Control
packets go with the same priority". Same for CAPWAP Data (when using
DTLS)
	 
	(c) Fix the problem
	 
	I do not think that (a) is an option as the protocol is broken
(and I am not sure how this will pass IESG muster).
	(b) is a potential option though it has undesirable side-effects
of serializing everything.
	 
	The right thing to do will be (c), though I could be convinced
to go with (b). I do not think that (a) is a realistic option.
	 
	Thanks.
	 
	-Puneet

	From: Mani, Mahalingam (Mani) [mailto:[email-masked]] 
	Sent: Friday, March 23, 2007 1:47 AM
	To: capwap
	Subject: [Capwap] Issue 253: Handling of multiple priority
streams over DTLS in datapath.

	This issue has been filed in the tracker a few days ago - to
record this problem. The person who raised the issue earlier in the list
and prior sessions has not responded so far on the email thread
(referred to the attached email for the thread).

	The WG should decide whether it needs (formal text in the
protocol draft) to address this issue. It has been marked as a bug now.
If the WG does not believe the problem is serious enough to be addressed
(for reasons of deployment model or other) - then the issue will be
deferred.

	If WG believes the problem needs to be addressed - we welcome a
proposal (253 suggests one approach) and text to go with it.

	Thanks,

	-mani

---

From: Scott G Kelly <[email-masked]>
Date: Thu, 29 Mar 2007 06:31:33 -0700

I agree with Pat. Personally, I don't see this being an issue for
control plane traffic (it is too sparse, and should remain so). I think
it could turn out to be an issue for data plane (I believe I'm the one
who originally opined on this), but that's not yet clear.

Real world deployment experience will make it clear, and we have
multiple options open to us if we need to address it.

Pat Calhoun (pacalhou) wrote:
> ------------------------------------------------------------------------
>