Subject: [Capwap] Issue #3: MTU Discovery Requirement

From: Margaret Wasserman <[email-masked]>
Date: Wed, 18 Jul 2007 10:35:44 -0400

Lars Eggert and Magnus Westerlund raised an issue with the WG  
regarding the
lack of a Path MTU Discovery mechanism in CAPWAP.  We can either  
introduce
this type of mechanism (to avoid fragmentation) or we can limit our  
message
size to the minimum MTU (512 bytes for IPv4, 1280 bytes for IPv6).

 > Specifically, I remember a discussion that
 > concluded that CAPWAP would need to have a mechanism to decide  
what MTU
 > to use and would need to default to a minimum MTU size (512  
bytes?) when
 > no other information was available, in order to avoid  
fragmentation.  Is
 > that still a concern regarding the CAPWAP protocol?  If so, do you  
(or
 > Dave or Lars) have any advice about how we might address it?

Yes, you likely need to have a MTU discovery mechanism to be avoid
needing to use very conservative packet sizes. But there should be
possible to implement something like the MTU discovery method described
in RFC 4821 in the CAPWAP protocol.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Smitha Smitha (ssmitha)" <[email-masked]>
Date: Wed, 18 Jul 2007 21:20:21 +0530

Margaret,

Could we reserve packet types to do MTU discovery? We can then use that
packet type say "path mtu request" and "path mtu response" along with
the path MTU payload described in the draft. 

Thanks
smitha

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 8:06 PM
To: capwap
Subject: [Capwap] Issue #3: MTU Discovery Requirement

Lars Eggert and Magnus Westerlund raised an issue with the WG regarding
the lack of a Path MTU Discovery mechanism in CAPWAP.  We can either
introduce this type of mechanism (to avoid fragmentation) or we can
limit our message size to the minimum MTU (512 bytes for IPv4, 1280
bytes for IPv6).

 > Specifically, I remember a discussion that  > concluded that CAPWAP
would need to have a mechanism to decide what MTU  > to use and would
need to default to a minimum MTU size (512
bytes?) when
 > no other information was available, in order to avoid fragmentation.
Is  > that still a concern regarding the CAPWAP protocol?  If so, do you
(or  > Dave or Lars) have any advice about how we might address it?

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 23 Jul 2007 14:29:56 -0700

As I stated in my other e-mail, LWAPP based devices have been available
for nearly three years, and we have many million such devices deployed
today. These are deployed in campuses, branch offices, home offices.
They connect through private and public networks, using Frame Relay,
PPPoE, Ethernet, WiMAX, etc. To date, the only time we ran into problems
was with a PPPoE deployment, which forced us to reduce our MTU size. I
agree that a dynamic MTU discovery method makes sense, but disagree that
a default of 512 is necessary.

The original comment did mention that CAPWAP includes some padding
capabilities, which is correct and I include here for informative
purposes:
<text>
4.6.30.  MTU Discovery Padding

   The MTU Discovery Padding message element is used as padding to
   perform MTU discovery, and MUST contain octets of value 0xFF, of any
   length.

    0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |  Padding...
     +-+-+-+-+-+-+-+-

   Type:   30 for MTU Discovery Padding

   Length:   variable

   Pad:   A variable length pad.
</text> 

What is missing in the current specification is guidance on how it
should be used. To that end, I propose adding some new text, which
follow the first sentence of the paragraph below:

<text>
5.1.  Discovery Request Message
[...]
   Upon receiving a Discovery Request message, the AC will respond with
   a Discovery Response message sent to the address in the source
   address of the received Discovery Request message.  Once a Discovery
   Response has been received, if the WTP decides to establish a session
   with the responding AC, it MAY use the Discovery Request/Response
   messages for the purposes of MTU Discovery.  In this instance, the
   Discovery messages are used for probing purposes, as defined in [12],
   and use the MTU Discovery Padding message element (see Section
4.6.30) for
   padding purposes.
</text>

PatC

---

From: "Smitha Smitha (ssmitha)" <[email-masked]>
Date: Tue, 24 Jul 2007 06:05:41 +0530

Pat,

So, when the WTP receives a discovery response and decides that it needs
to initiate a DTLS session with the AC on a certain 'Control IPv4
interface', it would send a discovery request destined to that interface
- and this could be for MTU discovery?

Also, the AC would need to know the MTU to the WTP, so do we simply
assume that it is the same as that between the WTP and AC? If not, we
need to define how to use the MTU discovery padding in the reverse
direction too.

If we do not have a low default MTU - we would need to wait till the MTU
has been found out for the WTP to join the AC - this could lead to
delays in join.

Thanks
smitha 
-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Tuesday, July 24, 2007 3:00 AM
To: Margaret Wasserman; capwap
Subject: Re: [Capwap] Issue #3: MTU Discovery Requirement

    0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |  Padding...
     +-+-+-+-+-+-+-+-

   Length:   variable

<text>

PatC

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 30 Jul 2007 09:00:55 -0700

I suppose a sentence stating that the response needs to be padded to
ensure it is the same size as the request. Would that work?

PatC 

-----Original Message-----
From: Smitha Smitha (ssmitha) 
Sent: Monday, July 23, 2007 5:36 PM
To: Pat Calhoun (pacalhou); Margaret Wasserman; capwap
Subject: RE: [Capwap] Issue #3: MTU Discovery Requirement

Pat,

Thanks
smitha
-----Original Message-----
From: Pat Calhoun (pacalhou)
Sent: Tuesday, July 24, 2007 3:00 AM
To: Margaret Wasserman; capwap
Subject: Re: [Capwap] Issue #3: MTU Discovery Requirement

    0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |  Padding...
     +-+-+-+-+-+-+-+-

   Length:   variable

<text>

PatC

---

From: "Smitha Smitha (ssmitha)" <[email-masked]>
Date: Mon, 30 Jul 2007 21:37:08 +0530

Yes that would. But this also means that there is a delay in the AP
joining the controller as it first needs to find the MTU. Maybe we could
assume a default low MTU and go ahead with join and then increase the
MTU after the discovery is complete.

Thanks
smitha

-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Monday, July 30, 2007 9:01 AM
To: Smitha Smitha (ssmitha); 'Margaret Wasserman'; 'capwap'
Subject: RE: [Capwap] Issue #3: MTU Discovery Requirement

PatC 

-----Original Message-----
From: Smitha Smitha (ssmitha)
Sent: Monday, July 23, 2007 5:36 PM
To: Pat Calhoun (pacalhou); Margaret Wasserman; capwap
Subject: RE: [Capwap] Issue #3: MTU Discovery Requirement

Pat,

Thanks
smitha
-----Original Message-----
From: Pat Calhoun (pacalhou)
Sent: Tuesday, July 24, 2007 3:00 AM
To: Margaret Wasserman; capwap
Subject: Re: [Capwap] Issue #3: MTU Discovery Requirement

    0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |  Padding...
     +-+-+-+-+-+-+-+-

   Length:   variable

<text>

PatC