PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
draft-bberry-pppoe-credit-06

Here is the comment which Mark asked the TSVWG chairs to
solicit - from Sally Floyd, ICIR.  The document is no problem,
but Sally does offer some advice the authors might like
to take.

Sure, this is a quick review of the flow control mechanisms in "PPP
Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics".

The flow control seems sound to me, and I don't think that this is
damaging to the Internet.  (As I understand it, the point of the
flow control is to keep the sending node from sending too fast for
the receiving node to handle, and not as congestion control.  PPP
didn't need any flow control because the assumption was that the
receiver could receive at the link rate.)

However, there are a few things that could be more clearly addressed
in the draft, as I say below.  I should say at the beginning that
I don't have expertise in either PPP or in PPPoE.

For a flow-controlled PPPoE session, flow credits are granted
out-of-band in the Discovery Stage, or in-band with Credit Tags,
containing FCN (Forward Credit Notification) and BCN (Backward
Credit Notification) fields.  In the PADG packet granting credits,
the FCN gives the number of additional credits granted *to* the
peer, and the BCN gives the remaining credits that have been granted
*by* the peer.

Out-of-band credit management with PADG and PADC packets:
The draft is very clear that a PADG packet granting credits is
responded-to by a PADC packet.  For the PADC packet, "the Credit
Tag FCN represents the absolute credits remaining that have [been]
granted to the peer by the node."  It might be worth it to add a
phrase saying that this information is simply echoed from the PADG
packet.  (I assume this is the case.)

In-band credit management:
The draft says that the in-band credit management is done with
Credit Tags, as illustrated in page 18.  Is it the case that for a
Credit Tag in a Session Stage packet, the FCN and BCN are interpreted
as in the PADG packet, and that there is no "response" Session Stage
packet with the FCN and BCN fields interpreted as in the PADC packet?
Or not?  It would be good for the text to address this explicitly.

Duplication?:
Is the assumption that packets will never be duplicated
between the two nodes?  If not, then some text should be adding
explaining why duplication would not cause a problem, e.g.,
with the peer thinking that credits had been granted twice.
(For example, for the PADG packet I assume that the Sequence
Number Tag would take care of this.)

Transmission errors:
On p. 9, there is a discussion that "much larger credit mismatches
can occur if there are transmission errors.  To correct these larger
errors, the BCN fields of the PADG and PADC packets from a peer
should be used by a node to set the credit values of its peer."

I assume that there are already mechanisms in PPPoE for a node to
decide when to retransmit a PADG or PADC packet?

What about transmission errors in the Session Stage, when PADG and
PADC packets aren't used?  Are there other mechanisms that take
care of transmission errors in this case?

Security:
The security session says the following:
"It is recommnded that the Service Tag and Session ID always be
validated prior to processing credits."

Why is this *recommended*, instead of required?  A little more
discussion might be useful.


A few typos, noted in passing:

P. 6: "that have granted to the peerby" ->
  "that have been granted to the peer by"

P. 9: "recieving" -> "receiving"

The "TVL" acronym wasn't expanded.

This document is targeted towards radio links. Radio links, and especially mobile radio links, have rapidly changing quality parameters.
I am not convinced that this extension can really deal with such situations.

However, that seems to make this document the ideal candidate for an experimental protocol (instead of informational document) to figure out whether it is really useful.