Subject: RE: LAST CALL: draft-ietf-ipvbi-nabts-03.txt

From: Dan Zigmond <[email-masked]>
Date: Mon, 28 Jun 1999 11:22:05 -0700

Sorry for the delay in responding to you.  I think most of the discussion on
PPP vs. SLIP occurred at our face-to-face meetings.  Although it was raised
a couple times, the consensus was that there is lots of good implementation
experience with the SLIP-like framing, that it's been used for several years
now, and that the benefits of changing didn't out-weight the risks of
fragmenting the market if not all the existing implementations were able to
switch over quickly.  

I guess the bottom line is that we basically agreed that we wish we had
started with PPP framing, but we didn't and it would be too hard to move to
it so late in the process.

I'll see if I can dig up the minutes on this point for you.

	Dan

---------------------------------------------------
Dan Zigmond
Senior Manager, Interactive Television Technology
WebTV Networks, Inc.
[email-masked]
---------------------------------------------------

-----Original Message-----
From: Grenville Armitage [mailto:[email-masked]]
Sent: Friday, June 18, 1999 3:25 PM
To: Dan Zigmond
Cc: [email-masked]'
Subject: Re: LAST CALL: draft-ietf-ipvbi-nabts-03.txt

Dan,

Dont want to be a pain, but can you point me to an archive of
discussions surrounding the WG's thoughts on using compressed
HDLC-like framing (as per PPP) instead of SLIP, and the longer
term goal (or non-goal) of being able to interleave high priority
tiny-grams within longer IP packets? (e.g. Real Time Framing
extensions to PPP/HDLC in draft-ietf-issll-isslow-rtf-05.txt can
do this, nothing equivalent is defined for SLIP, ... )

I'm sure the discussions been had, I just can't find record of it.
I might even suggest it be captured in an appendix to the I-D
since others are bound to wonder (in the future) about the
choice of non-standard SLIP :)

(Note, I'm only referring to PPP encaps/framing rather than
using PPP state machines which I recognize cannot be deployed
easily due to the uni-directional nature of the link...)

My intrigue is aroused because I observe that HDLC-like
framing can be reduced to simple FS delimiters (equivalent
to SLIP's END byte) and an Escape byte for when FS delimiters
appear in the data stream. Same overhead as SLIP, but more
widely implemented. Your use of 1 and 2 octet 'schema'
fields preceding the user packet is pretty much the same as
the PPP Protocol Field space (which is already administered
by IANA I believe). You could get a new PPP protocol field value
assigned to represent what you currently call Schema 0. Other
schemas can be developed and assigned their own code points.
A 32 bit HDLC-like FCS might replaced the current 32 bit CRC.
The nett effect is to reduce the number of codepoint spaces
managed by IANA, for little to no in-band additional overhead
(I'm madly waving my hands a little at this point by assuming
we can ditch the HDLC Addr/Control pre-header 0xFF03 too).

Of course, I've probably missed some key 'gotcha' here :)

cheers,
gja

Dan Zigmond wrote:
> 
> So this is a revision of our latest Internet-Draft, based on the feedback
we
> received form our Area Directors and reported to the list last month.  I
> think it addresses all of the concerns raised, as well as Wayne Carr's
> question about MTU.
> 
> I would like to re-start our working group last call on this draft today.
> Please take some time and look it over, and post to the list any questions
> or concerns you have.  If we're all still in agreement, I'd like to send
> this to the IESG for consideration as a Standards Track RFC in two weeks,
on
> July 2nd.
> 
> Happy reading.
> 
>         Dan
> 
> ---------------------------------------------------
> Dan Zigmond
> Senior Manager, Interactive Television Technology
> WebTV Networks, Inc.
> [email-masked]
> ---------------------------------------------------

________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs, Lucent Technologies

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 28 Jun 1999 15:53:06 -0400

Hi Dan,

That was my guess for the reasoning. I wonder if there's been
any face to face discussions on the issue of interleaving
small 'real time' packets onto a SLIP-framed ipvbi stream?
(I conceded it may be outside the design scope for the current
ipvbi work) I'm not sure I can come up with a reasonable
example of its use, but large packets tie up the ipvbi 'serial
line' for quite some tens of msec....

It would be valuable to future IETFers if the reasons for SLIP,
and the real-time interleave (non)considerations were documented
(even a few sentences) in the first released ipvbi spec.

cheers,
gja

-- 
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies