Subject: [Capwap] <Interim>: Issue 173: What happens when a message does not fit within a CAPWAP frame?

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Sun, 4 Feb 2007 18:22:48 -0700

Prior discussions captured in the Issue tracker: 

*          Pre-interim Response: CAPWAP fragmentation should address
this.

*          If "control message" rather than control frame - this needs
to be addressed (Dave Perkins)

-         WTP receiving a response message > max-message-size(WTP)

-         What if Sender (AC) knows max-message-size(WTP) limit

*          If the WTP cannot support reassembly of messages > some_size;
it is an Implementation issue.

Status: Open (Need more clarification on the perceived problem)

Resolution:

*         Minimum supportable max-CAPWAP message size: per discussions
related to Issue 229 - it was proposed to be set at 1468 octets - per
DTLSMtuUpdate command.

*         At discovery phase the AC will disclose the max-max CAPWAP
message size it can handle.

*         Discussions related to other issues (such as nominal
certificate-chain length and cert-sizes in DTLS authentication in
control-path) and CAPWAP message size led to proposal of 4K as the
maximum CAPWAP message size.

*         Dave Perkins raised a further concern about setting a finite
limit of 4K (or higher such as 64K as per current -04) about its
acceptability. Upon suggestion by our AD DanR, Margaret drafted a query
to the Transport ADs. The responses are being attached. The gist f the
response

o        Discussion of path-MTU discovery is suggested.

o        Having a limit of 4K is not objectionable - but providing a
means of negotiating it is preferred.

o        Suggests providing us with an advisor to handle congestion
control issues in control and datapaths at higher layers.

*         In summary, we have a min-max of 1468 and a negotiable max-max
with an upper bound of 4K (down from 64K) octets proposed. (The AC
proposes the upper bound). The discussions went back and forth between
negotiating max-max or simply requiring both ends (AC & WTP) to support
4K. I believe the final agreement was on negotiating if required.

This is posted here for WG discussion, acceptance/consensus.

Regards,

-mani

Subject: Re: Question for Transport ADs
From: "Lars Eggert" <[email-masked]>, "Lars Eggert" <[email-masked]>
To: "ext Magnus Westerlund" <[email-masked]>, "ext Magnus Westerlund" <[email-masked]>
Cc: "Romascanu, Dan \(Dan\)" <[email-masked]>, "Margaret Wasserman" <[email-masked]>, "Gellert Dorothy \(\(Nokia-SIR/MtView\)\)" <[email-masked]>, "Mani, Mahalingam \(Mani\)" <[email-masked]>, "David Kessens" <[email-masked]>, <[email-masked]>, "Romascanu, Dan \(Dan\)" <[email-masked]>, "Margaret Wasserman" <[email-masked]>, "Gellert Dorothy \(\(Nokia-SIR/MtView\)\)" <[email-masked]>, "Mani, Mahalingam \(Mani\)" <[email-masked]>, "David Kessens" <[email-masked]>, <[email-masked]>
Date: Fri, 26 Jan 2007 13:38:23 +0200

Hi,

On 2007-1-26, at 11:15, ext Magnus Westerlund wrote:
> I don't think there are any Transport issues with you limiting your  
> control messages to a maximum size of 4K.

I think there are, and they are similar to the issues we recently  
discussed for the CRISP protocol.

First off, IP fragmentation is optional in RFC1122 (Section 3.3.3).  
That means that CAPWAP would at least need to require that the  
underlying IP stack implements fragmentation.

But there is more in Section 3.3.3 of RFC1122:

	(a)  In general, no host is required to accept an IP
	     datagram larger than 576 bytes (including header and
	     data), so a host must not send a larger datagram
	     without explicit knowledge or prior arrangement with
	     the destination host.  Thus, MMS_S is only an upper
	     bound on the datagram size that a transport protocol
	     may send; even when MMS_S exceeds 556, the transport
	     layer must limit its messages to 556 bytes in the
	     absence of other knowledge about the destination
	     host.

Meaning that unless you somehow know the PMTU, you must not send a  
datagram larger than 576 bytes (unless you have a mechanism to  
recover, such as the new-style PMTUD, which I don't think is the case  
here). Simple UDP-based protocols usually know nothing about the  
PMTU, which is why DNS, SIP, etc. all make sure to not send packet  
longer than 500-odd bytes.

*If* you require CAPWAP to run over a single link only, you could  
conceivably argue that the link MTU gives you knowledge about what  
datagram size the peer can receive. But even then, 4K is too large on  
most links. And I'm not sure whether CAPWAP wouldn't be deployed  
across multi-hop paths.

The easy fix: Limit the message size to 500-odd bytes. But I'm not  
sure if this is feasible for CAPWAP.

(The larger issue behind this and the issues with CRISP is that IP  
fragmentation was never meant to be anything more than a band-aid -  
depending on it for the basic operation of a higher-level protocol is  
just asking for trouble. For starters, on many platforms, the first  
packet sent to an unknown station over Ethernet-like link usually  
cannot be reassembled, because the logic that queues packets while  
the ARP lookup takes place drops all but the first fragment...)

> You will need to think how you are going to handle congestion  
> control between the AC and WTP for CAPWAP. Control traffic as being  
> locally generated definitely needs some consideration around  
> congestion. Also as it isn't  obvious that the higher layer traffic  
> is necessarily congestion controlled some consideration for the  
> data traffic seems also in order. In addition you will have the  
> interesting interaction problem between higher layer congestion  
> control and any CAPWAP mechanism in this regards. We should discuss  
> providing you with some adviser on this.

+1

Lars

Subject: Re: FW: Question for Transport ADs
From: "Magnus Westerlund" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>
Cc: "Lars Eggert" <[email-masked]>, "Margaret Wasserman" <[email-masked]>, "Gellert Dorothy \(\(Nokia-SIR/MtView\)\)" <[email-masked]>, "Mani, Mahalingam \(Mani\)" <[email-masked]>, "David Kessens" <[email-masked]>, <[email-masked]>
Date: Fri, 26 Jan 2007 02:15:05 -0700

Hi everyone,

I don't think there are any Transport issues with you limiting your 
control messages to a maximum size of 4K. That is assuming that there 
are no limit for the data payload sizes forwarded by the CAPWAP 
protocol. My personal opinion is that not providing a way of negotiating 
this seems like a bad idea. Especially as you seem to have a 
configuration step in your setup. But if the WG likes to limit the 
protocol it seems to me that this is your right.

I took a glance at the CAPWAP protocol specification. Great that you 
included MTU Padding. However I am missing any discussion on how to 
perform the MTU discovery. It might be worth taking a look at 
draft-ietf-pmtud-method-11 (currently in RFC-editor queue). I strongly 
recommend that you make some form of PMTUD a normative to support 
feature of the protocol. That way CAPWAP can benefit from any improved 
MTU sizes.

In regards to the fragmentation mechanism. I have no idea about what 
operational environments you expect to exist on the link between the AC 
and WTP. Some discussion on the impact of the fragmentation may be 
needed. Having badly matched MTU capabilities between the STA -> WTP 
link compared to the WTP->AC seems a recipe for bad performance.

You will need to think how you are going to handle congestion control 
between the AC and WTP for CAPWAP. Control traffic as being locally 
generated definitely needs some consideration around congestion. Also as 
it isn't  obvious that the higher layer traffic is necessarily 
congestion controlled some consideration for the data traffic seems also 
in order. In addition you will have the interesting interaction problem 
between higher layer congestion control and any CAPWAP mechanism in this 
regards. We should discuss providing you with some adviser on this.

Cheers

Magnus Westerlund

Romascanu, Dan (Dan) skrev:
> Lars, Magnus, 
> 
> Please see the following message from the CAPWAP WG. We would appreciate
> a fast and informative answer. 
> 
> Dan
> 
> -----------------
> 
> Dear Transport ADs,
> 
> In the CAPWAP protocol, we define CAPWAP control messages that are sent
> between the CAPWAP access controller (the AC) and a CAPWAP- enabled
> wireless access point (the WTP).  CAPWAP is a UDP/IP-based protocol that
> uses DTLS for security.
> 
> The CAPWAP control messages are of variable length based on the message
> type and the size of the message elements included in the message (some
> of which are variable length and some of which are  
> optional).   Long messages will be fragmented into multiple CAPWAP  
> packets and reassembled into a single CAPWAP message on the other side,
> using a default MTU of 1468 bytes.  Please note that these packets
> contain CAPWAP-specific control traffic only, and they are sent between
> an AC and the set of WTPs that are controlled by that AC.  Data traffic
> that is sent through the WTP/AC is handled in another channel.
> 
> At our interim meeting this week, the CAPWAP WG reached consensus on
> setting a fixed maximum CAPWAP control message size of 4K bytes.  
> CAPWAP is based on currently deployed technologies, and some of the
> deployed devices currently use maximum message sizes as small as 1700
> bytes.  The WTPs are typically low-end devices, and they may not be
> capable of reassembling arbitrarily large packets, so we felt that a
> limit was necessary.  There is no realistic combination of operations
> and message elements in the CAPWAP spec that comes close to 4K, and it
> would also be possible in most of the longer message cases (e.g.  
> statistics events) for the sender to break a set of message elements
> across more than one CAPWAP message.
> 
> During the meeting, David Perkins asserted that the IESG could have
> issues that would result in a DISCUSS about a protocol that includes a
> fixed maximum message size, rather than negotiating the maximum message
> size dynamically between the two ends.  We were told that the Transport
> ADs could have a problem with this approach, and that you could require
> a mechanism that allowed both ends to assert the maximum message size
> that they can receive as part of session establishment.
> 
> Could you let us know if you would have a problem with the concept of
> using a fixed maximum message size, rather than exchanging these
> capabilities at runtime?  If so, could you explain why?
> 
> 
> 
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

Subject: FW: Question for Transport ADs
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Lars Eggert" <[email-masked]>, "Magnus Westerlund" <[email-masked]>
Cc: "Margaret Wasserman" <[email-masked]>, "Gellert Dorothy \(\(Nokia-SIR/MtView\)\)" <[email-masked]>, "Mani, Mahalingam \(Mani\)" <[email-masked]>, "David Kessens" <[email-masked]>, <[email-masked]>
Date: Thu, 25 Jan 2007 12:59:24 -0700

Lars, Magnus, 

Please see the following message from the CAPWAP WG. We would appreciate
a fast and informative answer. 

Dan

-----------------

Dear Transport ADs,

In the CAPWAP protocol, we define CAPWAP control messages that are sent
between the CAPWAP access controller (the AC) and a CAPWAP- enabled
wireless access point (the WTP).  CAPWAP is a UDP/IP-based protocol that
uses DTLS for security.

The CAPWAP control messages are of variable length based on the message
type and the size of the message elements included in the message (some
of which are variable length and some of which are  
optional).   Long messages will be fragmented into multiple CAPWAP  
packets and reassembled into a single CAPWAP message on the other side,
using a default MTU of 1468 bytes.  Please note that these packets
contain CAPWAP-specific control traffic only, and they are sent between
an AC and the set of WTPs that are controlled by that AC.  Data traffic
that is sent through the WTP/AC is handled in another channel.

At our interim meeting this week, the CAPWAP WG reached consensus on
setting a fixed maximum CAPWAP control message size of 4K bytes.  
CAPWAP is based on currently deployed technologies, and some of the
deployed devices currently use maximum message sizes as small as 1700
bytes.  The WTPs are typically low-end devices, and they may not be
capable of reassembling arbitrarily large packets, so we felt that a
limit was necessary.  There is no realistic combination of operations
and message elements in the CAPWAP spec that comes close to 4K, and it
would also be possible in most of the longer message cases (e.g.  
statistics events) for the sender to break a set of message elements
across more than one CAPWAP message.

During the meeting, David Perkins asserted that the IESG could have
issues that would result in a DISCUSS about a protocol that includes a
fixed maximum message size, rather than negotiating the maximum message
size dynamically between the two ends.  We were told that the Transport
ADs could have a problem with this approach, and that you could require
a mechanism that allowed both ends to assert the maximum message size
that they can receive as part of session establishment.

Could you let us know if you would have a problem with the concept of
using a fixed maximum message size, rather than exchanging these
capabilities at runtime?  If so, could you explain why?

Subject: Re: Question for Transport ADs
From: "Magnus Westerlund" <[email-masked]>
To: "Lars Eggert" <[email-masked]>
Cc: "Romascanu, Dan \(Dan\)" <[email-masked]>, "Margaret Wasserman" <[email-masked]>, "Gellert Dorothy \(\(Nokia-SIR/MtView\)\)" <[email-masked]>, "Mani, Mahalingam \(Mani\)" <[email-masked]>, "David Kessens" <[email-masked]>, <[email-masked]>
Date: Fri, 26 Jan 2007 07:31:40 -0700

Hi,

See inline some comments on this.

Lars Eggert skrev:
> Hi,
> 
> On 2007-1-26, at 11:15, ext Magnus Westerlund wrote:
>> I don't think there are any Transport issues with you limiting your 
>> control messages to a maximum size of 4K.
> 
> I think there are, and they are similar to the issues we recently 
> discussed for the CRISP protocol.
> 
> First off, IP fragmentation is optional in RFC1122 (Section 3.3.3). That 
> means that CAPWAP would at least need to require that the underlying IP 
> stack implements fragmentation.

As CAPWAP implements its own fragmentation I don't see this being an issue.

> 
> But there is more in Section 3.3.3 of RFC1122:
> 
>     (a)  In general, no host is required to accept an IP
>          datagram larger than 576 bytes (including header and
>          data), so a host must not send a larger datagram
>          without explicit knowledge or prior arrangement with
>          the destination host.  Thus, MMS_S is only an upper
>          bound on the datagram size that a transport protocol
>          may send; even when MMS_S exceeds 556, the transport
>          layer must limit its messages to 556 bytes in the
>          absence of other knowledge about the destination
>          host.
> 
> Meaning that unless you somehow know the PMTU, you must not send a 
> datagram larger than 576 bytes (unless you have a mechanism to recover, 
> such as the new-style PMTUD, which I don't think is the case here). 
> Simple UDP-based protocols usually know nothing about the PMTU, which is 
> why DNS, SIP, etc. all make sure to not send packet longer than 500-odd 
> bytes.

That is why I strongly recommend that CAPWAP defines PMTUD for itself to 
determine what MTU it should use. That way one can hopefully avoid 
fragmentation in most cases. At least as long as the MTU between the 
networks are reasonable matched. Preferably the path between the WTP and 
the AC has an MTU that are at least MTU(between STA and WTP) + CAPWAP 
overhead. Thus avoiding fragmentation of data messages. Depending on the 
packet loss rates encountered the fragmentation of control messages may 
or may not be an issue. If one expects to work in high loss rate 
environments then one may need to consider some mechanism that allows 
NACKing fragments and retransmitting them.  This is of course also 
dependent on message size. Already a 4K message may end up in up to 8 
fragments. If loss rates are in the range of 1% or more then you are in 
trouble.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

Subject: Re: Question for Transport ADs
From: "Lars Eggert" <[email-masked]>, "Lars Eggert" <[email-masked]>
To: "ext Magnus Westerlund" <[email-masked]>, "ext Magnus Westerlund" <[email-masked]>
Cc: "Romascanu, Dan \(Dan\)" <[email-masked]>, "Margaret Wasserman" <[email-masked]>, "Gellert Dorothy \(\(Nokia-SIR/MtView\)\)" <[email-masked]>, "Mani, Mahalingam \(Mani\)" <[email-masked]>, "David Kessens" <[email-masked]>, <[email-masked]>, "Romascanu, Dan \(Dan\)" <[email-masked]>, "Margaret Wasserman" <[email-masked]>, "Gellert Dorothy \(\(Nokia-SIR/MtView\)\)" <[email-masked]>, "Mani, Mahalingam \(Mani\)" <[email-masked]>, "David Kessens" <[email-masked]>, <[email-masked]>
Date: Fri, 26 Jan 2007 16:35:48 +0200

On 2007-1-26, at 16:31, ext Magnus Westerlund wrote:
> Lars Eggert skrev:
>> On 2007-1-26, at 11:15, ext Magnus Westerlund wrote:
>>> I don't think there are any Transport issues with you limiting  
>>> your control messages to a maximum size of 4K.
>> I think there are, and they are similar to the issues we recently  
>> discussed for the CRISP protocol.
>> First off, IP fragmentation is optional in RFC1122 (Section  
>> 3.3.3). That means that CAPWAP would at least need to require that  
>> the underlying IP stack implements fragmentation.
>
> As CAPWAP implements its own fragmentation I don't see this being  
> an issue.

You're right. I should read stuff more carefully before making  
statements about it. Forget most of what I said about 1122.

> That is why I strongly recommend that CAPWAP defines PMTUD for  
> itself to determine what MTU it should use. That way one can  
> hopefully avoid fragmentation in most cases.

Agreed. If CAPWAP can come up with some knowledge about the PMTU  
(either because stuff is on the same link, or by running something  
more clever), that value should be used as the CAPWAP fragment size.

If nothing is known about the PMTU, the default CAPWAP fragment size  
should be 512 bytes or so, to avoid excessive IP fragmenting.

Lars

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 5 Feb 2007 08:15:36 -0800

My recollection of the agreed upon resolution, at the meeting - not the
final decision, was that we would state that implementations had to be
capable of receiving frames of up to 4K. There was no agreement on
introducing some negotiation of the frame size. I believe Dorothy
Stalney owns this issue and was going to send proposed text.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Mani, Mahalingam (Mani) [mailto:[email-masked]] 
	Sent: Sunday, February 04, 2007 5:23 PM
	To: capwap
	Subject: [Capwap] <Interim>: Issue 173: What happens when a
message does notfit within a CAPWAP frame?

	*          Pre-interim Response: CAPWAP fragmentation should
address this.

	*          If "control message" rather than control frame - this
needs to be addressed (Dave Perkins)

	-         WTP receiving a response message >
max-message-size(WTP)

	*          If the WTP cannot support reassembly of messages >
some_size; it is an Implementation issue.

	Resolution:

	*         Minimum supportable max-CAPWAP message size: per
discussions related to Issue 229 - it was proposed to be set at 1468
octets - per DTLSMtuUpdate command.

	*         At discovery phase the AC will disclose the max-max
CAPWAP message size it can handle.

	*         Dave Perkins raised a further concern about setting a
finite limit of 4K (or higher such as 64K as per current -04) about its
acceptability. Upon suggestion by our AD DanR, Margaret drafted a query
to the Transport ADs. The responses are being attached. The gist f the
response

	o        Having a limit of 4K is not objectionable - but
providing a means of negotiating it is preferred.

	o        Suggests providing us with an advisor to handle
congestion control issues in control and datapaths at higher layers.

	*         In summary, we have a min-max of 1468 and a negotiable
max-max with an upper bound of 4K (down from 64K) octets proposed. (The
AC proposes the upper bound). The discussions went back and forth
between negotiating max-max or simply requiring both ends (AC & WTP) to
support 4K. I believe the final agreement was on negotiating if
required.

	Regards,

	-mani

---

From: "Dorothy Stanley" <[email-masked]>
Date: Mon, 5 Feb 2007 10:16:29 -0800

Mani,

My notes on the discussion regarding the proposed resolution for Issue 173
largely agree with yours.
I believe we agreed that (a) a device must be capable of receiving a
reassembled message of 4096 bytes (4K)
and we also (b) discussed adding the ability for a device to indicate the
maximum size that it can receive in the Join
Request/Response messages, as the "negotiation" mechanism - I don't recall
that we closed on the negotiation
piece. It sounds like the subsequent input from the transport ADs is that a
negotiation mechanism should be added.

If so, we would need text along the lines of:

To support (a), at the end of Section 4, add:

A CAPWAP implementation MUST be capable of receiving a reassembled CAPWAP
message
of length 4096 bytes.

To support (b):
Insert a new message element:

4.5.xx.  Maximim Message Length

   The Maximum Message Length message element value is used by
   the AC to inform the WTP and by the WTP to  inform the AC of the maximum
   CAPWAP message length that it can  receive.

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |   Max Message Length       l
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type:   xx for Maximum Message Length

   Length:   2

   Maximum Mesage Length:   An 16-bit unsigned integer indicating the
maximum message length

Add this message element, in the "MAY lists in 6.1 Join Request and 6.2 Join
Response
messages, with descriptions of what inclusion of the elements indicates.

Possibly add to (a) above:
A CAPWAP implementation MAY indicate that it supports a higher maximum
message
length, by including the Maximum Message Length message element (add
reference) in the Join
Request message or the Join Response message.

Comments welcome,

Thanks,

Dorothy Stanley
On 2/4/07, Mani, Mahalingam (Mani) <[email-masked]> wrote:
> •          Pre-interim Response: CAPWAP fragmentation should address this.
>
> •          If "control message" rather than control frame – this needs to
> be addressed (Dave Perkins)
>
> –         WTP receiving a response message > max-message-size(WTP)
>
> –         What if Sender (AC) knows max-message-size(WTP) limit
>
> •          If the WTP cannot support reassembly of messages > some_size;
> ·         Minimum supportable max-CAPWAP message size: per discussions
> related to Issue 229 – it was proposed to be set at 1468 octets – per
> DTLSMtuUpdate command.
>
> ·         At discovery phase the AC will disclose the max-max CAPWAP
> ·         Discussions related to other issues (such as nominal
> control-path) and CAPWAP message size led to proposal of 4K as the maximum
> CAPWAP message size.
>
> ·         Dave Perkins raised a further concern about setting a finite
> acceptability. Upon suggestion by our AD DanR, Margaret drafted a query to
> the Transport ADs. The responses are being attached. The gist f the response
>
> o        Having a limit of 4K is not objectionable – but providing a means
> of negotiating it is preferred.
>
> ·         In summary, we have a min-max of 1468 and a negotiable max-max
> with an upper bound of 4K (down from 64K) octets proposed. (The AC proposes
> the upper bound). The discussions went back and forth between negotiating
> max-max or simply requiring both ends (AC & WTP) to support 4K. I believe
> the final agreement was on negotiating if required.
>
>
>
> ---------- Forwarded message ----------
> To: "ext Magnus Westerlund" <[email-masked]>, "ext Magnus
> Westerlund" <[email-masked]>
> ---------- Forwarded message ----------
> ---------- Forwarded message ----------
> Please see the following message from the CAPWAP WG. We would appreciate a
> fast and informative answer.
>
> Dan
>
> -----------------
>
> Dear Transport ADs,
>
> between the CAPWAP access controller (the AC) and a CAPWAP- enabled wireless
> access point (the WTP).  CAPWAP is a UDP/IP-based protocol that uses DTLS
> for security.
>
> type and the size of the message elements included in the message (some of
> which are variable length and some of which are
>
> using a default MTU of 1468 bytes.  Please note that these packets contain
> CAPWAP-specific control traffic only, and they are sent between an AC and
> the set of WTPs that are controlled by that AC.  Data traffic that is sent
> through the WTP/AC is handled in another channel.
>
> bytes.  The WTPs are typically low-end devices, and they may not be capable
> of reassembling arbitrarily large packets, so we felt that a limit was
> necessary.  There is no realistic combination of operations and message
> elements in the CAPWAP spec that comes close to 4K, and it would also be
> possible in most of the longer message cases (e.g.
>
> During the meeting, David Perkins asserted that the IESG could have issues
> that would result in a DISCUSS about a protocol that includes a fixed
> maximum message size, rather than negotiating the maximum message size
> dynamically between the two ends.  We were told that the Transport ADs could
> have a problem with this approach, and that you could require a mechanism
> that allowed both ends to assert the maximum message size that they can
> receive as part of session establishment.
>
> ---------- Forwarded message ----------
> ---------- Forwarded message ----------
> To: "ext Magnus Westerlund" <[email-masked]>, "ext Magnus
> Westerlund" <[email-masked]>