Subject: Re: Last Call: Transmission of IPv6 Packets over IEEE 1394 Networ ks to Proposed Standard

From: Mike Teener <[email-masked]>
Date: Thu, 22 Feb 2001 11:59:15 -0800

I think we should hold off on this. There have been considerable problems
with the performance of IP1394 in PCs and other OHCI-based platforms due to
the FIFO-model data transfer (forces an interrupt for each received 1394
packet). I think we should consider using a direct memory model data
transfer in the future (OHCI is optimized for this), and IPv6 offers us an
opportunity for a changeover.

=============================================================
Michael D. Johas Teener
Chief Technical Officer, Zayante, Inc.
269 Mt. Hermon Rd. #200, Scotts Valley, CA 95066-4000, USA
voice: +1-831-461-4901  fax: +1-831-461-1394 http://www.zayante.com
mailto: [email-masked] PGP IDs: RSA 0x177754E1, D-H/DSS 0x3179D202

> ----------
> From:         Thomas Narten
> Reply To:     Thomas Narten
> Sent:         Tuesday, February 20, 2001 3:47 AM
> To:   [email-masked]
> Subject:      FWD: Last Call: Transmission of IPv6 Packets over IEEE 1394
> Networks to Proposed Standard
>
> Any comments?
>
> ------- Forwarded Message
>
> From: The IESG <[email-masked]>
> To: IETF-Announce: ;
> Cc: [email-masked]
> Date: Mon, 19 Feb 2001 14:50:14 -0500
> SUBJECT: Last Call: Transmission of IPv6 Packets over IEEE 1394
>          Networks to Proposed Standard
> Reply-to: [email-masked]
>
>
> The IESG has received a request from the IPNG Working Group to consider
> Transmission of IPv6 Packets over IEEE 1394 Networks
> <draft-ietf-ipngwg-1394-01.txt> as a Proposed Standard.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by March 5, 2001.
>
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-1394-01.txt
>
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
>
> ------- End of Forwarded Message
>
>

---

From: Kenji Fujisawa <[email-masked]>
Date: Fri, 23 Feb 2001 13:08:06 +0900

>opportunity for a changeover.

As we discussed in IP1394 WG at the early stage, we have to negotiate
the memory address between paticular two nodes to utilize memory-model.
It may be another overhead, and we can not use it for broadcast/multicast.
Although we might have an extension to utilize the memory-model in the future,
I believe we need the FIFO-model as a baseline.

Best Regards,

Kenji Fujisawa

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 23 Feb 2001 15:17:15 +0100

> opportunity for a changeover.

Playing devils advocate:
If RFC 2734 is so broken that we can't have an IPv6 specification that
uses the same low-level delivery mechanism, doesn't that mean that
we should immediately deprecate (make historic, whatever) RFC 2734?

If this is so broken, how come nobody has asked about a new 1394 WG
until the last call of the IPv6 spec appeared?

Seriously, if there is need in the community to open up RFC 2734 to
use a different low-level delivery mechanism, I fail to see how holding
up IPv6 over 1394 will in any way make specifications using the new
delivery mechanism come into existence any sooner.

So please help correct my confusion,
  Erik

---

From: Peter Johansson <[email-masked]>
Date: Fri, 23 Feb 2001 09:31:11 -0800

>we should immediately deprecate (make historic, whatever) RFC 2734?

It's been my impression that the IETF has a long history of advancing
documents towards final standardization at a stately pace; this allows time
to discover, by way of implementation, if fine-tuning is required.

I don't believe that RFC 2734 is in need of immediate deprecation, but I
would slow its standards progress for the same reasons cited to slow the
progress of Draft-IETF-IPNGWG-1394-01.

>until the last call of the IPv6 spec appeared?

The point of view that RFC 2734 requires some revision has been evolving at
the same time that work progressed on Draft-IETF-IPNGWG-1394-01 in the Next
Generation (IPv6) working group. That work, to a certain extent, has been
"under the radar" with respect to the larger IEEE 1394 community. Some of
us, such as myself, had some awareness of the project, but insufficient
time to devote to active involvement. Now that there is increased awareness
of a performance problem that merits attention, the question has been asked.

There are resources available to commence an IP1394 working group to
examine these issues.

>delivery mechanism come into existence any sooner.

I think the concern is that we are better off with a comprehensive solution
that addresses all of the problems. To turn your question upside down,
Eric, a delay in advancing Draft-IETF-IPNGWG-1394-01 will not make a new,
better solution come into existence sooner. Our diligent efforts will do
that. But delaying matters will leave the things open for the development
of a better solution; certifying Draft-IETF-IPNGWG-1394-01 may be perceived
(by some) as foreclosing the issue.

I agree with Mike Teener's conclusion that the widespread adoption of IPv6
affords us an opportunity to redo portions of RFC 2734 and "get it right".

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 26 Feb 2001 09:17:07 +0100

> better solution come into existence sooner.

It's Erik, unless you are referring to somebody else ...

> Our diligent efforts will do

In what way would the IPv6 1394 specification going to proposed standard
close the door any more than RFC 2734 has already closed the door?
Specifications can be easily revised and extended.

> affords us an opportunity to redo portions of RFC 2734 and "get it right".

I don't see fixing RFC 2734 in any way being impeeded on advancing
the IPv6 specification. In fact, the IPV6 specification refers to 2734
for most of the 1394 specifics, thus once a revised 2734 appears the edits
necessary to the IPv6 over 1394 specifications are likely to be minor.
(You can read the few pages in draft-ietf-ipngwg-1394-01.txt and convince
yourself.)

The reason I'm concerned about your line of reasoning is because
it errects obstacles against the IETF having specifications for both
IPv4 and IPv6 so that, from a specification perspective, we don't
delay deployment of IPv6. Thus having IPv6 specifications that are at
least as good as the IPv4 specifications is required.
But delaying publication of an IPv6 specification just because the
IPv4 specification needs to be improved works against removing ostacles
for IPv6 deployment, and might work against IPv* over 1394.

  Erik

---

From: Peter Johansson <[email-masked]>
Date: Tue, 27 Feb 2001 10:36:57 -0800

>for IPv6 deployment, and might work against IPv* over 1394.

I think you've clearly identified the point of disagreement. For some of us
active with IEEE 1394 (myself included), the viewpoint "from a
specification perspective" is too narrow for a quality decision. We believe
from a broader viewpoint (one that considers effective deployment of an
efficient IPvX over IP1394 solution) that there is significant merit to NOT
giving a signal that IPv6 over IEEE 1394 work is complete. Perhaps this is
not the message the IESG intends to communicate when it advances an
Internet-Draft to Proposed Standard, but my experience causes me to believe
that it is the message received by many.

I don't have anything new to add to arguments already advanced. For what
its worth, I think no one wishes an obstacle to IPv6 standards. But there
is a desire to commence and complete, promptly, a superior solution to RFC
2734.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 28 Feb 2001 11:14:34 +0100

> that it is the message received by many.

RFC 2026 says
   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

So there is nothing that says "complete" but merely "baked enough to start
implementing and learning from the implementations".

> is a desire to commence and complete, promptly, a superior solution to RFC

Looked at the recent discussion (on the ip1394 and iesg lists)
it seems like three individuals (yourself and Eric Anderson and Mike Teener)
have expressed reservations about RFC 2734 (hence indirectly against
draft-ietf-ipngwg-1394-00.txt) not providing the optimal performance for IP
over IEEE 1394.

This doesn't sound like a groundswell.

Are there others on the mailing list that think:
1. RFC 2734 is fine.
2. RFC 2734 needs to be scrapped and start over to get better performance.
3. RFC 2734 needs to be improved but the methods in RFC 2734 are needed
   at least for basic communication (including multicast and broadcast)
   with other mechanisms e.g. (physical DMA, asynchronous streams, and/or
   isochnronous transfer) being used for higher performance unicast transfers.

If possible I'd like to see opinions from more than 4 people - so please
send me your thoughts.

   Erik

---

From: Bob Hinden <[email-masked]>
Date: Wed, 28 Feb 2001 09:53:57 -0800

Erik,

>If possible I'd like to see opinions from more than 4 people - so please

I think that RFC2734 is fine as a first step.  As you pointed out it can be
revised later as we get more experience with IEEE1394.

What I would really like to see if for the IEEE to make 1394 simpler in
order to make it easier to run IP over it.  In my option 1394 is overly
complex and is trying to do too many things.  This complexity problem is a
common failing of new L2 technologies and in many cases it later turns out
that the only important service is IP.  This is, of course, out of scope of
the IETF and this working group, but I hope the folks in the IEEE will take
it seriously.

Bob