Subject: WG Last Call on IPv4/1394

From: Peter Johansson <[email-masked]>
Date: Thu, 1 Apr 1999 11:36:34 EST

I hate to be the "dog in the manger", but if IETF (IESG, whichever) policies
are anything like those of other standards organizations they will take
significant exception making a TECHNICAL change ("...and responses...") at a
point in time when they are reviewing the process we used to develop the
draft.

Perhaps we should seek some guidance from those who will be processing the
draft in the next phase?

Or maybe we should take out some inexpensive insurance and roll out Draft-
IETF-IP1394-IPv4-15 with "...and responses..." included.

Peter Johansson

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

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

[email-masked]

---

From: Peter Johansson <[email-masked]>
Date: Thu, 1 Apr 1999 13:39:09 EST

In a message dated 99-04-01 12:30:33 EST, [email-masked] writes:

<<Peter, previously your comments suggested that you were opposed to adding
the text into the draft. Now it sounds like it is okay with you if the text is
added. Is this correct?

Yes

---

From: Joseph Joy <[email-masked]>
Date: Thu, 1 Apr 1999 12:49:52 -0800

I think the text "and responses" MUST be added.

I also have some comments on the rest of the draft...

1. Sender max_rec and sspd in the ARP request/response format
(Figure 5). Do we still need these? Nodes need to query each
 other's bus_info_block to get the unique ID anyway. They can pick up the
max_rec at the same time. They can determine the send speed by reading the
speed map. I think these fields are a hold over from when NodeID used
 to be included in the ARP pkt.

2. In section 11, page 23, there is a reference to non-existent
 "section X".

The remaining points are to do with MCAP. There hasn't been
 much discussions on this wg on the subject of MCAP and I do
 not have a feel for how many implementations of MCAP exist
 today. There appears to be problems that would prevent robust
 communication among more than two hosts using MCAP, especially
 if the hosts have differing speed and max_rec capabilities.
 I could be wrong -- I would appreciate hearing from someone
 who has a robust implementation of MCAP that works under the
 latter conditions.

3. MCAP -- There is a CAUTION section 10., page 17 ("CAUTION: The
 working group has yet to define ..... shared use of a single
 channel number ... by more than one IP multicast address.").
 But section 10.5, page 21, first para, it says "More than one
 multicast group address MAY be mapped to a single Serial Bus
 channel number by means of separate group address descriptors."

4. In section 10.5, page 21, it states "The speed field
 specifies the maximum 1394 speed at which any of the senders
 within the multicast group is permitted to transmit data."
 Once a channel has been assigned for a particular group address
 (with a particular value for "speed",), only recipients which
 can receive at this or higher speeds can ever receive data on
 this group address. This is a problem.

5. In section 10.7, page 21, it states "The owner of an existing
 channel mapping that wishes to release the mapping SHALL commence
 a timer to measure the time remaining before the anticipated
 release of the mapping and its associated channel. Until the timer
 counts down to zero, the owner SHALL continue to transmit MCAP
 advertisements...." There could be times when the "owner of an
 existing channel" needs to urgently leave -- it can't afford to
 wait more then a couple of seconds, at best. There needs to be a
 provision in the protocol to deal with this situation.

The following comments apply assuming the protocol DOES allow
 multiple multicast group addresses to be mapped to a single
 channel (as section 10.5 indicates)...

6. It is not clear what needs to be done when a node that owns
 a particular channel wants to leave one multicast group address
 but not the others.

7. It is not clear what needs to be done when there is overlap
 in the advertisements each of which have different sets of
 partially-overlapping multicast group addresses. Following
 is a specific scenario involving nodes N1, N2, N3,
 channels C1, C2, C3, and multicast group addresses G1, G2 and G3:
 N1 sends advertisement (G1->C1, G2->C1)
 N2 sends advertisement (G2->C2, G3->C2)
 N3 sends advertisement (G3->C3)
Assuming nodeid(N1) < nodeid(N2) < nodeid(N3), it's not clear
 what nodes N1 and N2 need to do next.

Regards,

Joseph.
-----Original Message-----
From: Hattig, Myron [mailto:[email-masked]]
Sent: Thursday, April 01, 1999 9:31 AM
To: [email-masked]
Subject: Re: WG Last Call on IPv4/1394

Based on the discussion so far, I can justify adding the text or
moving the draft forward without it. I was hoping for more feedback
that might suggest a best direction.

Peter, previously your comments suggested that you were opposed to adding
the text into the draft. Now it sounds like it is okay with you
if the text is added. Is this correct?

I'd also like to hear Kenji's and Joseph's latest comments to see
if they thing the text MUST be added or not.

-myron

> -----Original Message-----
> From: Peter Johansson [mailto:[email-masked]]
> Sent: Thursday, April 01, 1999 8:37 AM
> To: [email-masked]
> Subject: WG Last Call on IPv4/1394
>
>

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 2 Apr 1999 08:52:52 -0800

Hi Joseph,

You bring up some good points. I'll just comment on the
technical points. I'll leave it to the editor
to address the editorial issues. Comments below.

-myron

> From: Joseph Joy [mailto:[email-masked]]
> Sent: Thursday, April 01, 1999 12:50 PM
> To: 'Hattig, Myron'; [email-masked]
> Subject: RE: WG Last Call on IPv4/1394
>
>

Sounds it's unanimous!! We will add it and rev the spec.

>  to be included in the ARP pkt.

Not exactly, in the discussions that led to including these feilds
was independent of the node ID. Nothing posted to the list since
we concluded those conversations gives cause to remove them now.

>  who has a robust implementation of MCAP that works under the

Most of the discussion about MCAP happened first half of 98 - WOW!!!
Sony and Intel showed interoperable implementations last June. We found
many improvements needed for the spec becuase of the interop test.

>  channel number by means of separate group address descriptors."

Great catch!! Section 10.5 page 21, first para, should be deleted or
modified. The problems with sharing a channel among multiple IP
addrs relates to deleting the channel number. If a single node ALWAYS
owns the multiple mappings, then it is no problem, but when multiple
nodes own different mapping using the same channel, additional protocol
that we have not defined is required so the different nodes can coordinate
the deallocation of the channel.

>  this group address. This is a problem.

This is the same problem with having speed in the ARP packet. We have
recognized in both cases - ARP and MCAP - that this is not a complete
solution but the WG thought it helped.  BTW, I was on the opposing side
of this debate, but we did have WG consensus and I see no reason to reopen
this issue.

>  provision in the protocol to deal with this situation.

Ummm, Is this a valid point? Can you think of any such scenarios that would
also not require a bus reset? In any case, suggestions on what to do if we
do have valid cases to worry about?

>  channel (as section 10.5 indicates)...

As stated, the WG did not want to tackle the exact issues you are bringing
up. The WG felt MCAP would not be used much therefore there was no need
to add complexity to MCAP.

---

From: Peter Johansson <[email-masked]>
Date: Fri, 2 Apr 1999 17:52:53 EST

In my opinion, a number of issues are still open and prevent the immediate
release of Draft-IETF-IP1394-IPv4-15. If I were to release that draft today,
the ONLY differences between it and its predecessor are a corrected reference
to section X and the addition of "...and responses" to the cross-bridge
prohibitions for ARP.

See comments interleaved below...

In a message dated 99-04-02 08:26:57 EST, [email-masked] writes:

<<1. Sender max_rec and sspd in the ARP request/response format (Figure 5).
Do we still need these? Nodes need to query each other's bus_info_block to
get the unique ID anyway. They can pick up the max_rec at the same time. They
can determine the send speed by reading the speed map. I think these fields
are a hold over from when NodeID used  to be included in the ARP pkt.>>

I think Myron summed things up pretty well, but...

Why do IP-capable nodes need to read each other's bus information blocks? I
can imagine implementations that don't.

The mythical SPEED_MAP is not likely to be available (even though it's
mandated) unless you keep it yourself. If you keep it yourself, everything
but the speed of the endpoint link is available from self-ID packets. The
sspd provides you with the link speed information without reading
configuration ROM.

By the way, the node ID field is STILL PRESENT in the ARP packet, it's just
that it's in the standard 1394 header and not in the ARP format. And it is
still put to all the same uses it was when present in the ARP format. That
is, one constructs a full, 64-bit unicast FIFO address from the
source_destination_ID field in the 1394 packet header and the
sender_unicast_FIFO_hi and sender_unicast_FIFO_lo fields in the ARP data.

<<2. In section 11, page 23, there is a reference to non-existent "section
X".>>

Fixed. The intended reference was to section 7, "Configuration ROM".

<<3. MCAP -- There is a CAUTION section 10., page 17 ("CAUTION: The working
group has yet to define ..... shared use of a single channel number ... by
more than one IP multicast address."). But section 10.5, page 21, first para,
it says "More than one multicast group address MAY be mapped to a single
Serial Bus channel number by means of separate group address descriptors.">>

If, in clause 10.5, you prohibit more than one multicast group address on a
single channel number, you close the door on what may be useful invention by
others. The intent of the document is to warn implementers that IF they do
this they will encounter problems not solved by the draft in front of
them---they will have to solve them on their own.

Where you read the language in clause 10.5 as contradictory to the cautionary
note at the beginning of section, I find them in harmony with each other.
Consequently I see this as an editorial issue and would like to improve the
text---but I am unsure as to what would help. Would it be useful to reiterate
the warning in clause 10.5?

<<4. In section 10.5, page 21, it states "The speed field specifies the
maximum 1394 speed at which any of the senders within the multicast group is
permitted to transmit data." Once a channel has been assigned for a
particular group address (with a particular value for "speed",), only
recipients which can receive at this or higher speeds can ever receive data
on this group address. This is a problem.>>

Perhaps the draft should discuss what happens if the MCAP advertisement
downgrades the speed. We need not address HOW the newcomer persuaded the
channel owner to downgrade the speed, only the fact that talkers need to
adjust to the slower requirement within some bounded period of time.

<<5. In section 10.7, page 21, it states "The owner of an existing channel
mapping that wishes to release the mapping SHALL commence a timer to measure
the time remaining before the anticipated release of the mapping and its
associated channel. Until the timer counts down to zero, the owner SHALL
continue to transmit MCAP advertisements...." There could be times when the
"owner of an existing channel" needs to urgently leave -- it can't afford to
wait more then a couple of seconds, at best. There needs to be a provision in
the protocol to deal with this situation.>>

Joseph, have you explored what happens if such an owner needs to leave
(urgently) and simply violates protocol? Is the problem self-healing or does
it cause other difficulties? I admit I don't have the time for this exercise,
but I think you should ascertain whether or not the problem in fact exists
before suggesting we fix it. Even better, perhaps you might propose a
solution.

<<The following comments apply assuming the protocol DOES allow multiple
multicast group addresses to be mapped to a single channel (as section 10.5
indicates)...>>

As Myron said, these are beyond the self-imposed scope of the IP1394 working
group.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Joseph Joy <[email-masked]>
Date: Fri, 2 Apr 1999 18:42:15 -0800

Thanks Peter and Myron for your responses.

Following is my take on the status on the issues raised in this thread:
1. [RESOLVED]ARP Pkts: sender_max_rec and sspd fields are to remain. I had
forgotten that
   the node ID info was still accessible (and hence assumed that nodes are
required to
   read bus_info to get the mapping from unique-id to node id). I stand
corrected.
2. [RESOLVED]Reference to non-existent "section X" In section 11, page 23 -
fixed.
3. MCAP: multiple multicast addresses should/should not be mapped to a
single channel.
   In response to Peter's comments: what is an implementation of MCAP based
STRICTLY on
   this draft supposed to do if it receives an MCAP advertisement which maps
multiple group
   addresses to the same channel? What is the recommended action to improve
chances
   of interoperability?  Should it ignore the advertisement?
4. MCAP: there is no provision for receivers with a lower max_rec to
participate in an
    established mcast session (this problem has no simple solution, and has
been
    debated in the WG before). I would like to see mention of the provision
to downgrade
    speed as Peter suggests.
5. MCAP: if a node currently "owning" a mcast channel needs to leave
urgently, it must
    induce a bus reset. This is not explicitly specified in the draft. The
specific
    scenerio I'm thinking of is if the user on a PC disables (via the UI)
the
    tcp/ip stack over 1394. In this situation the arp module
    can't wait around for the required channel expiry times. In this
situation,
    I'm ok with that fact that the arp module must induce a bus reset. I
don't
    see a solution (that would fit within MCAP as currently defined) other
than
    inducing a bus reset.

On a different topic...

With MCAP transfer of ownership, it' appears (based purely on thought
experiments) to be possible to get into situations when there is no owner of
a
previously allocated channel, or where a channel is de-allocated when it
shouldn't.
I hope someone in this WG can show that what I describe is actually a non
issue.

Following is one scenario:
       Node N1 wants to send on ip group address G1.    It sends a solicit.
       Node N2 (which is almost through winding down ownership of channel
C1) sends
             advertise (G1-> channel C1, expiry in 10 secs)
       N1 sends advertisement (G1->C1, exp in 60 secs), wanting transfer of
ownership of C1.
       The above advertisement from N1 is lost.
       N2 goes ahead and de-allocates C1, but N1 thinks that it is now the
owner of C1.
       A single lost packet has caused this to happen.

Regards,

Joseph.
-----Original Message-----
From: Peter Johansson [mailto:[email-masked]]
Sent: Friday, April 02, 1999 2:53 PM
To: [email-masked]
Subject: Re: WG Last Call on IPv4/1394

In my opinion, a number of issues are still open and prevent the immediate
release of Draft-IETF-IP1394-IPv4-15. If I were to release that draft today,
the ONLY differences between it and its predecessor are a corrected
reference
to section X and the addition of "...and responses" to the cross-bridge
prohibitions for ARP.

get the unique ID anyway. They can pick up the max_rec at the same time.
They

more than one IP multicast address."). But section 10.5, page 21, first
para,

Where you read the language in clause 10.5 as contradictory to the
cautionary
note at the beginning of section, I find them in harmony with each other.
Consequently I see this as an editorial issue and would like to improve the
text---but I am unsure as to what would help. Would it be useful to
reiterate
the warning in clause 10.5?

wait more then a couple of seconds, at best. There needs to be a provision
in

it cause other difficulties? I admit I don't have the time for this
exercise,

Regards,

Peter Johansson

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

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

[email-masked]