Subject: [Pppext] Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC

From: The IESG <[email-masked]>
Date: Thu, 16 Feb 2006 10:38:41 -0500

The IESG has received a request from the Point-to-Point Protocol Extensions WG to consider the following document:

- 'Accommodating an MTU/MRU greater than 1492 in PPPoE '
   <draft-arberg-pppoe-mtu-gt1492-02.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-03-02.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-arberg-pppoe-mtu-gt1492-02.txt

_______________________________________________
Pppext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Feb 2006 22:48:10 +0200 (EET)

On Thu, 16 Feb 2006, The IESG wrote:
> The IESG has received a request from the Point-to-Point Protocol 
> Extensions WG to consider the following document:
>

I think this is addressing one of operationally important aspects, but 
I'm not so sure about a couple of particular design decisions made, 
and would like to see them justified (or points to earlier 
discussions) or changed.

major discussion points
-----------------------

1)

This doc seems to define a PPPoE option 'PPP-Max-Payload'.  It talks 
of using PPP MRU option.  There is no PPP MTU option that I could see.

My question here is, should there be a PPP MTU option instead of a 
PPPoE option?  This would be a more generic solution to this part of 
the problem, and would also apply in non-PPPoE scenarios for 
signalling MTU.  Am I missing something ?

2)

MRU test procedure using MRU-sized Echo-Requests is disabled by 
default and to be used for debug purposes only.  I'm questioning 
whether this is wise.  The protocol would be much more robust against 
errors if it always used, once, during the PPP set-up, one roundtrip 
of MRU-sized packets.  This is not a bandwidth issue, because we're 
talking about fast DSL networks or Gigabit Ethernet.  This ensure that 
the higher MTU is actually supported and actually works as well (e.g., 
someone hadn't turned off jumbo frames).

So I'd argue it might make sense to put sending/receiving MRU-sized 
packets (e.g., some padding) right into the negotiation phase.

substantial comments
--------------------

==> first off, a major clarification request:  RFC1661 does not 
mention 'MTU' anywhere,

       <-------------- PPPoA -------------> <- PPPoE session ->

                                        +-----+            +-----+
     +--+              +---+            |     |            |     |
     |PC|--------------|CPE|------------|DSLAM|------------| BRAS|
     +--+    <ATM>     +---+    <ATM>   |     |   <GigE>   |     |
                                        +-----+            +-----+

     Fig. 3: Broadband network designs with PPPoA to PPPoE conversion.

==> surely the <ATM> part between PC and CPE should be something else? 
It's difficult to believe someone would be considering developing 
a new PPPoA mechanism which would require deploying ATM on the PCs :-)
This requires some tweaking to the figure and text.

    Since next generation broadband networks are built around Ethernet
    systems supporting baby-giants and jumbo frames with payload sizes
    larger than the normal Ethernet MTU of 1500 octets, a BRAS acting
    as a PPPoE server MUST support PPPoE MRU negotiations larger than
    1492 bytes in order to limit the amount of fragmented packets in
    network designs shown in section 1.

5.1 MRU Negotiations

==> this is a very confusing section.  It seems you're saying almost 
the same things about 3 times: at PPPoE pseudo-code, after that in a 
very confusing explanation of the pseudo-code, and then at the summary 
of the behaviour.  As these use slightly different terms, this left me 
uncertain of what the actual behaviour is. This section needs a 
rewrite to remove duplication of specification and to make it clearer.

mostly editorial
----------------

==> This has over half a dozen ID-nits, many of them blocking:
http://tools.ietf.org/wg/pppext/draft-arberg-pppoe-mtu-gt1492/draft-arberg-pppoe-mtu-gt1492-02.nits.txt

==> no refs in the abtract

     In the network design shown in figure 1, fragmentation is typically
     not a problem since the subscriber session is PPPoE end-to-end from
     the PC to the BRAS, so a PPP negotiated MRU of 1492 bytes is
     fully acceptable as it makes the largest PPPoE frame adhere to
     the standard Ethernet MTU of 1500 bytes.

==> well, there is ample evidence that fragmentation is a problem here 
as well (due to broken firewalls dropping ICMP errors that BRAS'es 
send), but the text is protocol-wise correct. Maybe reword to describe 
the problem, to something like:

     In the network design shown in figure 1, fragmentation is typically
     unavoidable since the subscriber session is PPPoE end-to-end from
     the PC to the BRAS, and the standard Ethernet MTU of 1500 sets
     the limit of the frames to 1492 octets.  As this causes issues
     with e.g., Path MTU Discovery, it would be desirable to be able to
     raise the maximum PPP payload size to at least 1500 octets.

.....

     In the network design shown in figure 2, fragmentation becomes a
     major problem since the subscriber session is a combination of
     IPoE and PPPoE. The IPoE typically negotiates a MTU of 1500 bytes.

==> the last sentence is misleading: IP over Ethernet does not 
'negotiate' anything.  You use the default 1500, or you manually 
configure both ends.  Slight reword needed.

       If (PPP-Max-Payload-Tag) Not Present
         Then PPP_MRU_Max = 1492
         Else PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8)

==> for clarity, I'd move 'Else ...' indentation left by two spaces.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: James Carlson <[email-masked]>
Date: Fri, 17 Feb 2006 16:38:19 -0500

> PPPoE option?  This would be a more generic solution to this part of 

I don't follow.  PPP is symmetric -- there are two MRUs negotiated,
one for each direction.  Your peer's MRU is your maximum (and default)
MTU.

How could we need another option for this?  Or how could one help?

What's really going on here is negotiation about the existence of a
usable path.  Unfortunately, the underlying protocol itself (other
than LLDP) doesn't provide a way to do this.  This new mechanism thus
doesn't solve the actual problem, but does at least allow consenting
peers to identify each other.  (In other words, I view it as just a
boolean.)

> whether this is wise.  The protocol would be much more robust against 

I don't think it is.  But we did discuss that during the document
review.

> ==> first off, a major clarification request:  RFC1661 does not 

It doesn't need to, I think.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Feb 2006 23:59:43 +0200 (EET)

> one for each direction.  Your peer's MRU is your maximum (and default)

Your peer's MRU is not directly your MTU, because the MTU could be 
lower as well (e.g., capped by the interface MTU).  But yes -- this 
was mentioned in the pseudo-code.

> peers to identify each other.  (In other words, I view it as just a

I guess the problem I was having here is that I didn't understand why 
a PPPoE MTU options would be useful (still don't).  After all, if both 
PPP endpoins would signal MRU = 2000 (for example), then PPPoE could 
just use that with no need for an extra option?  Looking back at the 
archives, it appears others have had related concerns, so I guess this 
is beating a dead horse..

> I don't think it is.  But we did discuss that during the document

I reviewed the mailing list archives for the last 6 months, and at 
least during that period I didn't see this discussed.

But let me qualify that.  "The protocol would be more robust against 
..." instead of "much more".  That is at least an objective statement: 
as the document specifies that all PPPoE servers MUST support this 
mechanism, sooner or later someone is going to misconfigure too high 
MTU usage when jumboframes aren't enabled, or someone is going to 
disable jumboframes somewhere on the path.  Currently there is no 
jumboframe spec that I'm aware of, and there is no way to recover or 
notice these situations that I can think of.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Feb 2006 22:48:10 +0200 (EET)

major discussion points
-----------------------

1)

2)

substantial comments
--------------------

                                        +-----+            +-----+
     +--+              +---+            |     |            |     |

5.1 MRU Negotiations

mostly editorial
----------------

....

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Feb 2006 23:59:43 +0200 (EET)

.." instead of "much more".  That is at least an objective statement:

---

From: "Peter Arberg" <[email-masked]>
Date: Sun, 19 Feb 2006 19:56:30 +1100

Hi Pekka,

thanks for your comments, I have added some comments inline.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Pekka Savola
> Sent: 17. februar 2006 23:00
> To: James Carlson
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Pppext] Re: Last Call: 'Accommodating an 
> MTU/MRU greater than1492 in PPPoE' to Informational RFC
> 
> > one for each direction.  Your peer's MRU is your maximum 
> >(and default) MTU.
> 

right, this is shown in the pseudo-code.

> a PPPoE MTU options would be useful (still don't).  After 
> all, if both PPP endpoins would signal MRU = 2000 (for example), then 
> PPPoE could just use that with no need for an extra option?  Looking back 
> at the archives, it appears others have had related concerns, so I 
> guess this is beating a dead horse..

When we published the first version of the draft, it was actually to do
just so, simply let the PPPoE endpoints negotiate a higher MRU than the 
RFC2516 limitation of 1492.

But during different vendor testing, it unfortunately became clear that
some older PPPoE clients would request 1500 in a MRU negotiation, but not
be able to handle it... sínce PPPoE servers = BRAS have been taking care
of this issue earlier and not allowed more than 1492 even if the client
asked for 1500, it has not been a problem so far.

But now we needed a way to differentiate the "new" clients who can handle
1500 when they ask for it and the "old" clients who can't.  The PPPoE TAG
is the proposal for this, to give better interoperability for higher MRU
negotiation.

This has been discussed on the list back in May-05.

> notice these situations that I can think of.

I agree it would be "more robust" following your suggestion, but this
was also discussed back in May-05, and it is a consious choice we made
and say Service Providers knows their network, and as such by disabling 
this functionality by default, we are saying that PPP session setup
time is more important than a per session setup security check, BUT 
at the same time we agree that a troubleshooting functionality is needed 
in case end-to-end connectivity can not be established.

Also we did include based on James suggestion the following warning because 
there is no jumbospec. 

---
   The procedure described in this document do not strictly conform 
   to IEEE standards for Ethernet packet size, but rely on a widely 
   deployed behavior of supporting jumbo frames on Ethernet segments.
---

cheers,
Peter

---

From: "Peter Arberg" <[email-masked]>
Date: Sun, 19 Feb 2006 21:05:25 +1100

Hi Pekka,

some more comments inline. 

> Sent: 17. februar 2006 21:48
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU 
> greater than 1492 in PPPoE' to Informational RFC 
> 

1) and 2) is responded to in earlier email.

> substantial comments

Correct, my comment is the same as James.  Instead of every say 
MRU and maximum MTU I simply say MTU/MRU, I do not think this can
cause to much confusion, especially when the pseudo code do show
that the interface MTU has to be considered. 

>        <-------------- PPPoA -------------> <- PPPoE session ->

I'm not talking about what people will consider moving forward, I'm 
talking about what is deployed today, and you will still find a large
number of ATM interface cards in PC's today. This drawing is simply to 
show what have been deployed earlier, and what the solution will have 
to be able to be backward compatible with.

> very confusing explanation of the pseudo-code, and then at 
> the summary of the behaviour.  As these use slightly different terms, 
> this left me 

I will be happy to see a suggetsion, I have rewritten this before based
on comments from the list, I'm not sure I can come up with a better
explanation than exist here.

I do not think it is the same information given 3 times, I do agree that
the pseudo code is explained (or tried explained) in english, but the
summary also describe what should happen if no PPP MRU negotiation happens, 
and as such clarifies the fact that RFC1661 is the most important factor
in setting MTU/MRU even if a "PPP-Max-Payload" TAG is received.

> http://tools.ietf.org/wg/pppext/draft-arberg-pppoe-mtu-gt1492/
> draft-arberg-pppoe-mtu-gt1492-02.nits.txt
> 
> ==> well, there is ample evidence that fragmentation is a 
> problem here as well (due to broken firewalls dropping ICMP errors 
> that BRAS'es send), but the text is protocol-wise correct. Maybe reword 
> to describe the problem, to something like:
> 

I don't think rewording the text will make the point any different, but
I do agree a fragmentation problem often can exist in this type of setup
as well, and it will also benefit from increasing the PPPoE MTU/MRU.

> configure both ends.  Slight reword needed.

Yes agree, negotiates is a wrong word to use, it should simply have
said "The IPoE typically use a MTU of 1500 bytes."

I have no problem issuing a v.3 of the draft with the above editorial
changes, and also editorial changes to remove the found "nits", and 
will do so based on James advise now or when the last-call is done.

thanks,
Peter

---

From: James Carlson <[email-masked]>
Date: Mon, 20 Feb 2006 13:44:01 -0500

> in case end-to-end connectivity can not be established.

I don't think it's a wise choice at all.  For those who perform the
check, the check can be done in parallel with everything else the link
does (such as IPCP negotiation), so there's no reason to suppose that
it will somehow affect session set-up time.

Plus, in the case where the test succeeds, it's very quick -- no
timeout required because the large size packet will get through and be
echoed back.

And more importantly, if there is a problem with the path, then the
failure mode will be quite obscure, painful, and difficult for mere
users to diagnose.

So, I don't think it's a good choice to offer at all, but since this
document seems to be reflecting some existing deployment practices or
implementations rather than design, I suppose I'm not overly concerned
if the advice has flaws.

---

From: James Carlson <[email-masked]>
Date: Mon, 20 Feb 2006 13:49:42 -0500

> is beating a dead horse..

I think it is.  What's really needed is some end-to-end mechanism
within 802 itself for making sure that the MTU on the path is
correct.  That mechanism doesn't really exist.

There are several problems here.  First of all, there are several
PPPoE implementations that will assume a fixed limit of 1492 (based on
requirements of the 802 the standards), no matter what PPP attempts to
negotiate.  So merely having the LCP MRU option show something larger
won't help -- the peer already "knows" that the path can't possibly be
that wide.

Now, it'd be reasonable to have LCP negotiate an MRU > 1492, and then
use LCP Echo-Request (in parallel with IPCP start-up) to verify that
the path really supports packets that large.  If it doesn't, then
restart LCP and negotiate a fixed 1492.  That wouldn't require any
protocol changes at all.

I think something like that is what you're suggesting.  It seems
reasonable to me, except that I think the draft authors wanted
explicit signaling between the peers to enable the new mode of
operation.

---

From: James Carlson <[email-masked]>
Date: Mon, 20 Feb 2006 14:29:28 -0500

> will do so based on James advise now or when the last-call is done.

I'd suggest waiting until the commentary has settled and then issuing
a new version.