Subject: RE: [pilc] RE: AD request / L2 Triggers Chapter Statement

From: Scott Corson <[email-masked]>
Date: Fri, 7 Jun 2002 17:00:36 -0400

> Wrong.  We absolutely NEED IP to change so that there is a standard 
> mechanism for ALL future L2s to communicate with IP from the bottom up.

Got to agree with Phil here.  Looking up from layer 2 (my current
perspective) this is clear and obvious.

> Imagine yourself as an L2.  
> How on earth are you going to send any kind
> of link quality assesment to IP?  THERE IS NO STANDARD MECHANISM
> CURRENTLY.  

The question in my mind is where to draw the line?

I agree with Phil in principle.  Pushing a standardized set of L2 signals up
to IP, and letting IP decide what it wants to do across a plethora a link
layers is the ideal approach.  However, these triggers need to be
*normalized* (i.e. have the *same* meaning across all link layers), for
example, as SIR values in one link layer are not comparable to those in
another.  Developing this understanding will take time.

A more timid, tentative step would be support for simple link UP/DOWN
triggers.  Standardization of behavior at this coarse granularity would be a
good start, and allow experience with wireless dynamics to be gained.  This
approach allows the link layer to decide when a link is good or bad, and
then make this decision known to IP.  IP can do what it likes, react as it
likes (or not) on its own timescale as appropriate.  The IP underbelly API
can evolve over time.

Thoughts?

-Scott

_______________________________________________
pilc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 7 Jun 2002 16:01:37 -0600 (MDT)

> From [email-masked]  Fri Jun  7 15:27:20 2002

(I didn't trim the bloated cc list not trimmed because I can't what it's
about.)

> ...
> ...

I'm sorry about this flame, but I can't hold it back any longer....

That something is clearly obviously needed does not imply that it
is or is not the business of the IETF.

You guys seem to be confusing the IETF with the ANSI, and demanding
the whole ANSI/ITU/IEEE signal-this and indicate-that inter-state
machine apparatus that is so beloved by those committee's go-ers.

You seem to be equating operating system and host functions with
over-the-wire behavior.  One has always been the concern of the IETF,
but the other has at best very rarely been a successful concern.  The
closest to success I can think of are the ex post facto descriptions
of sockets and at least partly ex post fact IPv6 socket extentions.

If you think you need a way for your layer 2 to tell IP something,
then your best hope is stop talking about IETF working groups and
write some code.  IETF talk is not going to define or implement the
functions you need.  No RFC is going to magically insert code into
your wireless phone operating systems.  Unless your market window
won't close for the next 2 or 3 years, you won't have any relevant
RFCs in time from the IETF.

Do you know so little about current and historic TCP/IP code that you
think that any of them don't already have many L2 triggers, signals,
indications, and other stuff?  Do you imagine that BSD sockets are
the only way for applications to talk to TCP?  Demanding that the IETF
standardize the functions that everyone who has written a network
driver knows about suggests that sort of narrow view.

Asside from fragment assembly, what state machine do hope to set off
with your L2 triggers?  Do you think that RED, ECN, and the other
things that have state machines are in host IP implementations?  When
they are in host implementations, are they in the IP code or in what
you probably consider L2 code?  Does your wireless host IP code have
enough of a state machine for the notion of "trigger" to make any sense?

I suppose instead you want your L2 triggers to reach through IP to
TCP to suggest that TCP do or stop doing or otherwise change.  Don't
you know that people have been doing such things for decades without
the let, leave, or hindrance of the IETF?

Was the WAP Forum such a wonderful success that you want to repeat
the experience inside the IETF?

Vernon Schryver    [email-masked]

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 10 Jun 2002 08:57:30 -0400

Hello Vernon,

BTW, the bloated CC list, is the list of co-authors for L2 triggers BOF
problem statement and drafts.  These are the folks that have volunteered
their precious time and expressed deep interest in this matter.

> of sockets and at least partly ex post fact IPv6 socket extentions.

If you have been following closely, you will have noticed that I did indeed
mention sockets.  In fact sockets is a top down approach.  I advocate a more
object oriented approach where the IP stack have member functions on
all sides, especially the dark underbelly where all the hidden art is.  I am
really tired have to wade through dozens of "ingenious implementations".

> RFCs in time from the IETF.

Hmm.  That is why we are having a BOF.  That is the first step in creating
a WG that will in turn create drafts and hopefully an RFC.  I really don't
get your point.  2-3 years is probably OK, but I have seen some things
move faster then that.

> driver knows about suggests that sort of narrow view.

Then you agree its an underspecified black art.  Perhaps it give you job
security.  It just gives me a headache each time I need to interface another
L2 to IP.

> enough of a state machine for the notion of "trigger" to make any sense?

What we are asking for is the interface and some rudimentary behavior.  
We believe that putting in the standardized doorway is the first step.

> the let, leave, or hindrance of the IETF?

Yes, precisely WHY it needs to be STANDARDIZED!!! You are making
my point for me.  Thanks!

> the experience inside the IETF?

I am not sure how/why you mention WAP.  We have nothing to do with
WAP.  Could you explain your mentioning of WAP?

Best regards,

Phil

---

From: James Carlson <[email-masked]>
Date: Mon, 10 Jun 2002 10:39:16 -0400

Phil Neumiller writes:
> [Vern Schryver wrote]

Sure, I can see why having interface standards would be nice, but
then, why the IETF at all?  Internal implementation details really
don't seem to me to be the domain of folks engineering protocols for
the Internet itself.

This seems more appropriate for The Open Group or some other such OS
interfaces standardization body.

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677