Subject: Re: IPv6 over ATM encapsulation

From: [email-masked]
Date: Sun, 23 Nov 1997 22:02:38 -0800 (PST)

>Francis Dupont and I were just discussing the possibility of removing the=
>null
>encapsulation option from draft-ietf-ion-ipv6-atm-00.txt.
>We think that's a good idea for two reasons:
>- the null encapsulation is fairly limiting and useless =
>- the less options there are, the likelier (and the better) one can =
>interoperate

I will make two points about interoperability 

1) If there is a default (and there is - LLC) which is mandatory
to implement then there is no interoperability problem. 

2) Systems today are required to assume that a remote party may
try to negotiate the encapsulation. That is, a system cannot assume
that in a SETUP there will only be one BLLI element, or that the 
first BLLI element will indicate LLC. It can assume that one of the 
BLLI elements will indicate LLC, otherwise there is a protocol error.
If the negotiation of an alternate encapsulation is prohibited
then this may lead to implementations that assume there will only
be one BLLI element and that it is LLC. This introduces a change
in the IPV4/ATM and IPV6/ATM behaviours which is likely to cause
interoperability problems rather than diminish them, given that
there are likely to be systems that speak both IPV4 and IPV6
and use the same signalling stack.

Bryan

---

From: Dan Grossman <[email-masked]>
Date: Mon, 24 Nov 1997 14:06:16 -0500

> and use the same signalling stack.
We put null encapsulation in RFC 1483 for a reason.  The reason was that for 
ATM VCs that only carry IPV4, a TCP SYN, FIN or ACK will exactly fit into one 
ATM cell (taking into account the AAL5 trailer) if no TCP or IP options are 
turned on.

Obviously, an IPV6 header barely fits into an ATM cell, even if no extension 
headers are used.  However, has anybody taken a look at whether there are 
frequent three-cell scenarios which could become two-cell scenarios by 
removing the SNAP header (common combinations of IPV6 extension headers, TCP 
options and/or very common user data that add up to 82-88 bytes?)  There was a 
thread earlier (which unfortunately got dropped) on the possibility of header 
compression for IPV4;  if we did something like that for IPV6, could we get 
TCP ACKs back down to one cell?

It seems that some people in the IP community snipe at ATM for the alleged 
cell tax.  If this is a sincere concern, then perhaps we ought to be looking 
not to preclude ways of reducing overhead to avoid crossing cell boundaries.

I'd like to see the null encapsulation retained for both PVCs and SVCs.

Dan

---

From: Albert Manfredi <[email-masked]>
Date: Mon, 24 Nov 1997 15:01:32 -0500

Dan Grossman wrote:

[ ... ]

> I'd like to see the null encapsulation retained for both PVCs and SVCs.

Seems to me that the "ATM cell tax" is a specious concern. Not that
reducing overhead isn't by itself A Good Thing, but to do this based
on "cell tax" doesn't stand the test of common sense.

Compare the individual clock pulses required of IP over ATM compared
with IP over 10Base-T Ethernet (or 10Base-anything, i.e.
Manchester), and ATM almost always wins out. This _includes_ ACK
frames.

The problem here is one of semantics in marketing, not real world.
To keep the playing field even, OC-3-based ATM should always have
been called "135 Mb/s." Alternatively, 10 Mb/s Ethernet should
always have been called 20Base-whatever, and FDDI should have been
called 125 Mb/s.

If an excess of complication is added only to appease the "cell tax"
contingent, perhaps I'm saying it's not justified by real arguments.
Cell tax is either small or non-existent compared with "4B/5B tax"
or "Manchester encoding" tax. Ultimately, one pays for baud rate,
not net bit rate.

Bert
[email-masked]

---

From: [email-masked] (Christian Huitema)
Date: Mon, 24 Nov 1997 15:47:55 -0500 (EST)

> always have been called 20Base-whatever, and FDDI should have been

Uh? the "cell tax" argument usually refer to the comparison of two well
defined stacks, IP>PPP>Sonet and IP>PPP>ATM>Sonet.  A classic case of
whether the overhead (cell) is worth the functionality (switching).
 Opinions are known to vary.

In any case, this discussion has only a minimal relation to the design and
implementation of IPv6.

-- 
Christian Huitema

---

From: Dan Grossman <[email-masked]>
Date: Mon, 24 Nov 1997 16:05:43 -0500

> Seems to me that the "ATM cell tax" is a specious concern. Not that
I agree.  But there are some people who make an issue of it.  
> on "cell tax" doesn't stand the test of common sense.
Well, ok, I think we can agree that reducing overhead is a Good Thing.  I 
would add that one reason is it's a good thing is that there are some who have 
unfounded concerns about ATM efficiency that should be addressed.
> with IP over 10Base-T Ethernet (or 10Base-anything, i.e.
... and Gigabit Ethernet
> always have been called 20Base-whatever, and FDDI should have been
The marketing issue is a real one: it makes for nice ad-hominem attacks.  And 
the 135 Mbit/s number assumes full utilization of the ATM cell payload: a 46 
byte datagram has 43% efficiency, while a 40 byte datagram has 90% efficiency.
> or "Manchester encoding" tax. Ultimately, one pays for baud rate,
I don't think it adds a lot of complexity.  The negotiation machinery is part 
of everybody's portable signalling software, and once it's in place, it's 
probably just a test and branch in the driver.  I think this little complexity 
 is justified a) by taking an argument away from the ATM haters b) by the fact 
that I don't think anybody's done for IPV6 any analysis along the lines of 
Ramon Caceres' thesis on the effects of SAR on IPV4. and c) Bryan's 
interoperability  arguments.

Rgds
Dan

---

From: Scott W Brim <[email-masked]>
Date: Mon, 24 Nov 1997 16:02:42 -0500

>In any case, this discussion has only a minimal relation to the design and

Right.  Please.

...Scott

---

From: Albert Manfredi <[email-masked]>
Date: Mon, 24 Nov 1997 16:13:56 -0500

Placed in order of importance,

> In any case, this discussion has only a minimal relation to the design and

True enough.

>  Opinions are known to vary.

Right, Christian. I know.

Let's look at the complete overhead picture, IP over Manchester, IP
over FDDI (4B/5B), and IP over ATM/SONET.

IP over Manchester = 50 percent overhead, + Ethernet + IP overhead.
Manchester requires two clocks per data bit.

IP over FDDI = 20 percent overhead, + FDDI + LLC + IP overhead.
4B/5B requires frive clocks for 4 data bits.

IP over ATM/SONET at OC-3 = 12.8 percent overhead + LLC + IP
overhead. ATM and SONET use scrambling to ensure a low DC content,
rather than extra clocks.

Even if you point just to the ACK frames, compared with Manchester,
ATM does better.

Bert

---

From: Paul Koning <[email-masked]>
Date: Tue, 25 Nov 1997 09:51:11 -0500

>>>>> "FFFFDan" == Dan Grossman <[email-masked]> writes:

 >>  If an excess of complication is added only to appease the "cell
 >> tax" contingent, perhaps I'm saying it's not justified by real
 >> arguments.  Cell tax is either small or non-existent compared with
 >> "4B/5B tax" or "Manchester encoding" tax. Ultimately, one pays for
 >> baud rate, not net bit rate.
 FFFFDan> I don't think it adds a lot of complexity.  The negotiation
 FFFFDan> machinery is part of everybody's portable signalling
 FFFFDan> software, and once it's in place, it's probably just a test
 FFFFDan> and branch in the driver.  I think this little complexity is
 FFFFDan> justified a) by taking an argument away from the ATM haters
 FFFFDan> b) by the fact that I don't think anybody's done for IPV6
 FFFFDan> any analysis along the lines of Ramon Caceres' thesis on the
 FFFFDan> effects of SAR on IPV4. and c) Bryan's interoperability
 FFFFDan> arguments.

The complexity issue isn't in the negotiation or configuration.  It is
in the fact that it introduces a second format in the fastpath.  

Ok, so it's optional, but that's beside the point.  Either it's
useful, in which case I should use it (and take the performance hit in
the fastpath) or it's not useful, in which case it would be preferable
not to have it exist.

The interesting question is: if it's useful to have null
encapsulation, why isn't it the default?  I've never heard of anyone
running anything other than IP over 1483 LLC encapsulation, so that
doesn't seem like the issue.  On the other hand, there is one thing
one does run alongside IP, i.e., ARP.  Which brings up another
question: is the option of null encapsulation actually meaningless
because 1577 doensn't work if you tried to use it?

	paul

---

From: Dan Grossman <[email-masked]>
Date: Tue, 25 Nov 1997 11:37:55 -0500

(I've cut the IPV6 list out, since they seem not to be interested)
> Dan,
> IPv6 header compression, as specified in draft-degermark-ipv6-hc-04.txt,
> has the goal of compressing the IPv6 and UDP/TCP headers down to 4-7
> octets.  However, it is really aimed at "low- and medium-speed links",
> to quote the draft, and you certainly wouldn't want to have to be doing
> the compression and decompression in software at OC3+ rates, or have to
> build hardware to do it.  Uncompressed TCP acks will fit in two cells
> whether or not LLC/SNAP headers are used.  I'm not close enough into an
> IPv6 implementation to say if there are any common packets that are
> exactly 82-88 octets in length, but I would tend to doubt it.
You're right about the SNAP header not being critical if you assume IPV6 
extension headers  and TCP options are less than 14 bytes, or greater than 20 
bytes. Are there reasonable combinations in that space?  If not, can we ensure 
there will never be?

> I would prefer to keep implementations and configuration simpler by
> not including null encapsulation on PVCs.
I would prefer to continue as we have:  SNAP encapsulation is the mandatory 
default, and Null encapsulation is a pre-negotiated option.  If 
implementations do not want to support the Null encapsulation, they don't have 
to.  Since it now appears the PVCs are the only issue on the table, this will 
also provide greater commonality between SVCs and PVCs.  Given the uncertainty 
about the effects of SAR on IPV6, and the "cell tax" attacks, it seems that 
this is the best thing to do.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 25 Nov 1997 11:08:52 -0500 (EST)

Dan,

Cheers,
Andy
________________________________________________________________________
Andrew G. Malis  [email-masked]  phone:978 952-7414   fax:978 392-1484
Ascend Communications, Inc.        1 Robbins Road     Westford, MA 01886