Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC

From: "Veera Tubati \(vtubati\)" <[email-masked]>
Date: Mon, 20 Feb 2006 13:09:27 -0800

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Monday, February 20, 2006 12:54 PM
> To: Veera Tubati (vtubati)
> Cc: Pekka Savola; [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater
> than1492 in PPPoE' to Informational RFC
> 
> Veera Tubati (vtubati) writes:
> > > We're talking about a single MTU-sized packet transmitted and one
> > > received on an Ethernet link.
> >
> > Correct, but it could be in the order of 20k or more sessions trying
to
> > come up at once after the outage of a BRAS box. For the broken
clients
> > asking for 1500, it is more overhead to timeout and retry something
> > else. Whatever can be avoided reasonably is a bonus.
> 
> So ... we're worried about a BRAS that is unable to handle the load of
> one extra packet for those 20K clients but that will perform
> "acceptably" when those same 20K clients are all actively using their
> links?
> 
> I don't quite understand, but it sounds to me like a design issue for
> the BRAS and not a protocol issue.  If it wants, that machine could
> sequence the link bring-up so that it spreads out the load, or it
> could just use a more capable hardware platform.

It is clear that is not an issue with the protocol, but seems there are
practical reasons which pushed for the birth of this draft.

Veera

> 
> > May be there would be cases where ISP is sure that their underlying
> > network and clients support 1500 MRU indeed...
> 
> I agree that consenting peers may do as they like, but it's not an
> optimization that makes sense to me.
> 
> --
> 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

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

---

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

> practical reasons which pushed for the birth of this draft.

That seems unrelated to the potential performance issue I thought we
were discussing.

In any event, the draft authors wanted explicit signaling because of
the behavior of the existing PPPoE implementations.  There's little
way to be _sure_ you're talking to a new one without checking.  (I
think a boolean would be sufficient for that, but I see no problem
with having an integer value instead.)

-- 
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: "Peter Arberg" <[email-masked]>
Date: Tue, 21 Feb 2006 23:17:55 +1100

I agree a boolean flag could as well have been used, but the initial
suggestion was for a value to set a hint for the max value the client
would be asking for, I also see no problem in this value.

I do think based on recent discussions that a little more precise 
pseudo code is needed, to make the pseudo code in line with the
tag description, that it's value is only a maximum hint if it's greater
than 1492, if for some strange reasons a client send a tag value
less than 1492 (don't ask me why it would ;) then the BRAS should
ignore the value and allow the MRU negotiation of upto 1492.

Also for the echo test, the recommendation ended up like it is, 
because the carrier feedback was they know their network, and as 
such do not expect major problems if/when they would enable the
new capability. It is the intend of the text that this is an adhoc 
test which can be performed by an administrator upon connectivity problems.

It will without a doubt make the solution more robust if the echo test
was performed upon setup, and we could change the recommendation to not
specific say this capability SHOULD be disabled, so changing it from
---
   This capability SHOULD be disabled by default, and SHOULD only be
   available for debug, test purpose.
---

to something like this:

---
   This capability MAY be disabled by default, but SHOULD be
   available for debug, test purpose.
---

if you think that will make it a little better.

cheers,
Peter

> Sent: 21. februar 2006 08:16
> Cc: [email-masked]; [email-masked]; Pekka Savola; [email-masked]
> Subject: RE: [Pppext] Re: Last Call: 'Accommodating an 
> MTU/MRU greater than1492in PPPoE' to Informational RFC
>

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Feb 2006 08:26:21 +0200 (EET)

> if you think that will make it a little better.

Couldn't we say even more than that, simply like:

     This capability SHOULD be used by default.

or:

     This capability SHOULD be used by default to verify that the
     negotiated MTU/MRU actually works.

That would allow anyone to disable it (or not implement it) and still 
be compliant with the spec.

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