RE: Re: Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC

Hi Pekka,

some more comments inline. 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Pekka Savola
> Sent: 17. februar 2006 21:48
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU 
> greater than 1492 in PPPoE' to Informational RFC 
> 
> 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:
> >
> > - 'Accommodating an MTU/MRU greater than 1492 in PPPoE '
> >   <draft-arberg-pppoe-mtu-gt1492-02.txt> as an Informational RFC
> 
> 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.
> 

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


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

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 ->
> 
>                                         +-----+            +-----+
>      +--+              +---+            |     |            |     |
>      |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.

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.


>     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.

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.


> 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.
> 

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.


>      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.

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

>        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
> 
> _______________________________________________
> Pppext mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/pppext
> 



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