Subject: [Pppext] Review of draft-bberry-pppoe-credit (Informational)

From: Mark Townsley <[email-masked]>
Date: Wed, 27 Jul 2005 16:23:37 +0200

This is an individual submission document for Informational publication. 
Without getting into whether PPPoE itself should have been strangled at 
birth or not, I would like a fair review of this document before 
advancing it. Please send comments to the authors and this list before 
August 24.

Thanks,

- Mark

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

---

From: James Carlson <[email-masked]>
Date: Wed, 27 Jul 2005 11:12:35 -0400

> advancing it. Please send comments to the authors and this list before 

I suppose I'm a bit curious why the existing RFC 1663 (PPP Reliable
Transmission) and RFC 1989 (PPP Link Quality Monitoring) protocols
weren't already sufficient for the job and, if not sufficient,
couldn't have been built on to solve the problem.  I don't see either
mentioned in the draft as related work.

I don't think I see a point to having flow control implemented here,
as the transport layers already know how to deal with loss by slowing
down.  Perhaps the real solution might be to fix the "limited
buffering" design problem in the affected devices that this draft
mentions rather than imposing a new protocol on the rest of the world.

There seems to be no description of how the "Receive only" flag might
be used.  Doesn't RFC 1661 already assume (and require) a
bidirectional link?  How could a valid and usable PPP link ever be
running over a "receive only" link?

This proposal seems to further degrade the already tortured PPPoE link
MTU.  If tag insertion is allowed with PPPoE Session Stage messages
(something that RFC 2516 didn't allow), then what happens to the link
MTU?  Further, I suspect that section 5 of the draft is misworded.
The magic value 0106 (which fortunately is not a legal PPP Protocol
ID) is used to distinguish the presence of this TLV, and the system
shouldn't just check for LCP.

One other note: I'm not sure what the "Resources" field is doing in
the PADQ message.  The amount of remaining battery power (!) doesn't
appear to have much to do with link quality.

-- 
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: Vernon Schryver <[email-masked]>
Date: Wed, 27 Jul 2005 09:27:28 -0600 (MDT)

> To: Mark Townsley <[email-masked]>
> Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational)
> Cc: [email-masked], Margaret Wasserman <[email-masked]>,
>         [email-masked], [email-masked]

Mark Townsley wrote:
> advancing it. 

Is that an entirely accurate description of the situation with the
document?  It seems to me that it is not really being proposed as
"Informational" document to describe something that is entirely
proprietary or purely experimental.  The authors have here in the
Pppext mailing list adverted to wanting the IETF's approval for their
plan to address a difficulty.  I think they have been open about hoping
and expecting that upon IETF publication, (other?) vendors will implement
and ship their solution.

Therefore, shouldn't the IETF consider all available alternatives to
fixing the difficulty?  Instead of pushing through this document and
compounding the PPPoE mess, shouldn't the IETF consider alternatives
including the one described in draft-haag-pppext-spppoe-00.txt?

Even if the IETF cannot decide, shouldn't alternatives get the same
support by Informational publication?

Doesn't the IETF now have technical criteria even for Informational RFCs?

Vernon Schryver    [email-masked]

---

From: Mark Lanzo <[email-masked]>
Date: Wed, 27 Jul 2005 11:57:36 -0400 (EDT)

> mentioned in the draft as related work.

I don't really see how these are connected.

The goal as suggested in the draft is not to create a "reliable" link.
It's more to avoid creating a hopelessly unreliable link.  The target
environment is one where a router is connected to a radio by 
by a fast link (an ethernet), and where there are multiple PPP sessions
being established between the router and the numerous remote nodes reachable 
by the radio.  The radio equipment itself doesn't maintain either a fast or
reliable connection to the other nodes in its contact list.  The radio 
equipment *does* buffer (possibly even on a per PPP connection basis), 
but has limited capacity.  The radio equipment may even include some limited
retransmission capability, but overall it's not going to provide a 
guaranteed delivery of packets.  Further, since the radio is a broadcast
mechanism and sharing the frequency with all the other nodes in that
network, the rate of packet delivery is very erratic and there's no
meaningful bandwidth which can be associated to the individual PPP
connections.

Imagine a bunch of ham radio operators running PPP on the mobile
radios in their cars, creating a very fluid network, and you'll
have a good mental picture of the target environment (the draft
doesn't seem to make this really clear).

Please note, BTW, that I am not trying to push or endorse the draft;
or trying to suggest that other methods may not also be worth
considering.  I'm just trying to add some background which may help
clarify the intent behind the draft.

-Mark Lanzo

---

From: Mark Townsley <[email-masked]>
Date: Wed, 27 Jul 2005 19:10:10 +0200

>including the one described in draft-haag-pppext-spppoe-00.txt?
I don't think draft-haag is talking about the same thing as draft-bberry.