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

Message from Bob Braden concerning state changes and status

----- Begin forwarded message:

From: Bob Braden
Subject: Re: Status of draft-bberry-pppoe-credit-
Date: Tue, Mar 28 14:48:41
To: rfc-editor@rfc-editor.org, townsley@cisco.com
Cc: bberry@cisco.com, hholgate@cisco.com, fenner@research.att.com, sratliff@cisco.com


  *> Editor,
  *>
  *> Can you give us insight into what is happening with this document? Why was it
  *> moved out of your RFC Ed Queue? Bill moved it out of the tracker state because
  *> he saw it transition out of your ed queue, now it has expired and died. I
  *> believe it to be approved from our side, but perhaps something went wrong in the
  *> handover?
  *>
  *> Thanks,
  *>
  *> - Mark
  *>
  *>

I have no idea what the message from the IETF Tracker State Update means.
We sent you a message back in February, asking for significant changes
following suggestions from two reviewers.  Bo Berry replied on Feb 18
that you planned to update the document, and we have no record of any
furhter action since then.


RFC Editor/bb

[Ballot discuss]
Requires IANA registry for new PPoE code values 0x0A etc and for new
PPoE tag values 0x0106 etc. Therefore cannot be an RFC Editor submission.
At least, must be coordinated with draft-arberg-pppoe-iana.

[Ballot comment]
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.

TSVWG Review

-------- Original Message --------
Subject: Re: Fwd: Review of flow control aspects of draft-bberry-pppoe-credit-04.txt
Date: Wed, 04 Jan 2006 23:04:29 -0800
From: Sally Floyd
To: James M. Polk
CC: Allison Mankin , Mark Townsley


>Would you be willing to provide us this quick review?

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.

- Sally
http://www.icir.org/floyd/

[Ballot comment]
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.

[Ballot discuss]
Requires IANA registry for new PPoE code values 0x0A etc and for new
PPoE tag values 0x0106 etc. Therefore cannot be an RFC Editor submission.
At least, must be coordinated with draft-arberg-pppoe-iana.

Attempts to introduce credit-based flow control at PPP level. I need
to know that the Internet (PPPEXT) and Transport (TSVWG) areas are
happy with this before concluding that it is non-damaging to the network.

PPPEXT REVIEW SUMMARY

-------- Original Message --------
Subject: Re: pppoe-credit
Date: Tue, 13 Dec 2005 09:28:44 -0500
From: James Carlson
To: Mark Townsley
References: <439ED28D.9020406@cisco.com>


Here's the current text.  I think everyone involved is unhappy with it
to one degree or another, so that must mean it's close to right.

The key issue here is that the author is using PPPoE as though it were
a serial wire emulation protocol.  That's not at all what PPPoE does,
and dragging it in that direction is compounding an existing error to
an unacceptable degree.  I do have some sympathy, and I can see how
the author ended up where he is by taking incremental steps that were
each seemingly somewhat reasonable, but I (and the other working group
members) just do not agree that the overall architecture is sound.

  "The PPP Extensions Working Group (pppext) has reservations about
  the desirability of the feature described in this document.  In
  particular, it solves a general problem at an inappropriate layer
  and it may have unpredictable interactions with higher and lower
  level protocols.  The techniques described in this document are
  intended for use with a particular deployment technique that uses a
  PPP termination separated from a radio termination by an Ethernet,
  and that has radio-side flow control for a slower PPP-only link to
  remote nodes.  Implementors are better advised to avoid split
  termination with inter-media protocol translation, and use standard
  Internet Protocol routing instead."

--
James Carlson, KISS Network                   
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 REVIEW SUMMARY

-------- Original Message --------
Subject: Re: pppoe-credit
Date: Tue, 13 Dec 2005 09:28:44 -0500
From: James Carlson
To: Mark Townsley
References: <439ED28D.9020406@cisco.com>


Here's the current text.  I think everyone involved is unhappy with it
to one degree or another, so that must mean it's close to right.

The key issue here is that the author is using PPPoE as though it were
a serial wire emulation protocol.  That's not at all what PPPoE does,
and dragging it in that direction is compounding an existing error to
an unacceptable degree.  I do have some sympathy, and I can see how
the author ended up where he is by taking incremental steps that were
each seemingly somewhat reasonable, but I (and the other working group
members) just do not agree that the overall architecture is sound.

  "The PPP Extensions Working Group (pppext) has reservations about
  the desirability of the feature described in this document.  In
  particular, it solves a general problem at an inappropriate layer
  and it may have unpredictable interactions with higher and lower
  level protocols.  The techniques described in this document are
  intended for use with a particular deployment technique that uses a
  PPP termination separated from a radio termination by an Ethernet,
  and that has radio-side flow control for a slower PPP-only link to
  remote nodes.  Implementors are better advised to avoid split
  termination with inter-media protocol translation, and use standard
  Internet Protocol routing instead."

--
James Carlson, KISS Network                   
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