vjs@rhyolite.SGI.COM (Vernon Schryver) (11/08/88)
Some time ago, I asked if "everyone" is going to use 802.2 LLC and RFC-1042 to encapsulate TCP/IP over FDDI. Only a couple of people responded, and they said yes. As I understand (or, more accurately, misunderstand) things, in the next MAC document 48-bit addresses will be required & 16-bit optional (good news!). That means, we have a 13 byte MAC header in front of every FDDI packet. If we add an 8-byte 802.2 LLC header in the style of RFC-1042, then the IP header starts at the wonderous offset of 21. A (mostly) standard 4.3BSD+VanJacobson/Karels TCP/IP on a machine which insists on natural alignment requires either byte-copying or aligned packets. Byte-copying is generally not a formula for speed. Copying from 1-byte to 4-byte alignment is "optimal" if you want to avoid saturating the network. If we used an 802.2 LLC encapsulation with a length of 3(mod 4) (e.g. 7 or 11), the IP header would be aligned. (It would also be aligned if you use 16-bit addresses with 5-byte MAC headers.) The only other evident solutions involve extra hardware. So, my current questions are: Does "everyone" still think RFC 1042 is a good idea? What have I misunderstood? Vernon Schryver Silicon Graphics vjs@sgi.com
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (11/11/88)
Suggestion: Instead of starting packet reception on an even byte boundary, what if you start it on an odd boundary? That way the odd header size will allow the IP and TCP headers to be on an even boundary. Will this be a problem for your hardware? Drew
postel@VENERA.ISI.EDU (Jon Postel) (11/19/88)
> Date: 7 Nov 88 23:07:17 GMT > From: sgi!vjs%rhyolite.SGI.COM@ucbvax.Berkeley.EDU (Vernon Schryver) > Subject: TCP/IP over FDDI > > As I understand (or, more accurately, misunderstand) things, in the > next MAC document 48-bit addresses will be required & 16-bit optional > (good news!). That means, we have a 13 byte MAC header in front of every > FDDI packet. If we add an 8-byte 802.2 LLC header in the style of > RFC-1042, then the IP header starts at the wonderous offset of 21. Does anyone think a 13 byte MAC header is a good idea? Do the guys on the 802 committee ever thing about anything bigger than a single bit? What favor can they possibly think they are doing to the users of FDDI networks by having a 13 byte header? --jon.
vjs@rhyolite.SGI.COM (Vernon Schryver) (11/20/88)
In article <8811190332.AA13232@venera.isi.edu>, postel@VENERA.ISI.EDU (Jon Postel) writes: > > Does anyone think a 13 byte MAC header is a good idea? > > Do the guys on the 802 committee ever thing about anything bigger than a > single bit? What favor can they possibly think they are doing to the > users of FDDI networks by having a 13 byte header? Some have helped calm my hysterical giggles by pointing out that AMD's 7982 DPC chip can shift by 0-3 bytes, so if you leave 3 bytes free at the start of every buffer, ... Others have said that 13 bytes of MAC + 3 bytes of LLC is just find. Perhaps the 802 guys were thinking, but only about 802.2. Could there be a new IP encapcapsulation in the style of RFC-1042 that would be 7 or 11 bytes long? Adding 3 bytes of 0 after the RFC-1042 802.2 header would waste no significant bandwidth, and would remove some craziness in drivers--even if you do use the DPC. One hears rumors and more of other chip sets. Vernon Schryver Silicon Graphics vjs@sgi.com
lougheed@CLASH.CISCO.COM (11/20/88)
No, a 13 byte MAC header is not a good idea if you want your protocols to run fast on modern processors. There are ways around this, however. Design your FDDI interface to optionally insert a pad byte on reception and delete a leading pad byte on transmission. Then you have a performance win if people use the eight byte SNAP header a la RFC-1042 and a performance problem if people use the simple three byte 802.2 LLC header. Now at least you can choose which protocol suite is going to take the performance hit. Kirk Lougheed cisco Systems
martillo@cpoint.UUCP (martillo) (12/05/88)
The mac-header size seems really perverted but isn't this issue really larger than just choosing a disgusting header size. Why do mac level addresses have to be so large? Why does each card have to have a unique mac address (not just for FDDI but apparently for the who 802.x technologies). IP or IP equivalent addresses need to be unique. But making physical layer addresses unique for the known universe is a waste of time. Better to have some authority on a given lan which assigns the locally significant mac layer addresses. Then 2 bytes would be sufficient. How many lans have more than 64k hosts on them? The real problem is that the IEEE with total misunderstanding views 802.2 which is a communications subnet protocol as an end-to-end protocol. To make the problem worse, 802.2 type 2 is based on LAPB which is a communications subnet access protocol. FDDI has added complexity because the FDDI committee refuses to accept that host with a dual mac FDDI controller is really attached to two separate physical networks and not one physical network (at least as I understand the current proposals). Joachim Carlo Santos Martillo