Subject: Q: Length field in draft-ietf-gsmp-encaps-03.txt

From: "Georg Kullgren" <[email-masked]>
Date: Fri, 17 Aug 2001 16:47:20 +0200

Hi

I've been reading draft-ietf-gsmp-encaps-03.txt and have some questions
regarding the Length field and the TCP encaps Type field.

Cut from the draft, TCP encaps:
-----------------------
4.1 Message Formats 

  GSMP messages are sent over a TCP connection. A GSMP message is 
  processed only after it is entirely received. A four-byte TLV 
  header field is prepended to the GSMP message to provide 
  delineation of GSMP messages within the TCP stream. 
   
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |        Type (0x88-0C)         |           Length              | 
   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   ~                         GSMP Message                          ~ 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

  Type 
               This 2-byte field indicates the type code of the 
               following message. The type code for GSMP messages is 
               0x88-0C (i.e. the same as GSMP's Ethertype).  

  Length:  This 2-byte unsigned integer indicates the total length 
               of the GSMP message only. It does not including the
               4-byte TLV header. 
----------------------

Is the type field really neccessary?
By using the specified port (6068) the message will already be
interpreted as GSMP.

Does the length field include vendor specific data?

Since we decided that message length in the GSMP header should include 
the vendor specific data the length field in the TCP encaps is no
longer needed, right?

The Ethernet encapsulation is defined as:
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      Destination Address                      | 
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                               |                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               | 
   |                         Source Address                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Ethertype (0x88-0C)       |                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               | 
   |                                                               | 
   ~                         GSMP Message                          ~ 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        Sender Instance                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Receiver Instance                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                              Pad                              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Frame Check Sequence                    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

What was the reason for adding the length field to the TCP encapsulation
but not to the Ethernet encapsulation?

The big question is:
Did we do The Right Thing in London when we (I) wanted to define the
length field in the GSMP header to include vendor specific data?

As the encaps draft is written, only TCP includes the length of the GSMP
message.
In ATM and Ethernet the drafts assumes that the API to the driver will
return the length of the data. I don't think we should assume this.
GSMP should be general enough not to care what kind of encapsulation
is being used or how the API is designed.

Any opinions?

Regards
/Georg
-- 
------------------------------------------------------------------------
Georg Kullgren            Nortel Networks AB    [email-masked]
System Architect          S:t Eriksgatan 115 A  Tel:   +46-8-50 88 36 18
Routing Architecture Lab  SE-113 85 Stockholm   Mobile: +46-703-14 36 18
                          Sweden                Fax:   +46-8-50 88 35 01

---

From: "tom worster" <[email-masked]>
Date: Fri, 17 Aug 2001 12:15:32 -0400

From: Georg Kullgren
> Is the type field really neccessary?

see below.

> By using the specified port (6068) the message will already be

y

> Does the length field include vendor specific data?

y

> the vendor specific data the length field in the TCP encaps is no

the purpose of the type and length is to provide something
for the receiver to "synchronise" on in the tcp byte stream.
such sync fields, like the long string of ones in bgp, must
be redundant in some way. we chose this scheme of a constant
type to search for followed by a length because it was fairly
easy to imagine a state machine that could track the message
boundaries in a byte stream. the type 0x880c is arbitrary. 
it could have been 0xffff (like in bgp) or anything else. 
it's just something for the sync state machine to hunt for
and then sync on.

the length field gives the number of bytes before the next 
type/length marker is expected in the byte stream (so it
includes the vendor specific data). if the 0x880c does not 
appear at the expected position then the receiver must start 
hunting again. if it wants to, the receiver can validate the 
length field of the tcp encaps with that of the gsmp message 
for extra confidence (a bit like a router that checks the ip 
total length against the ethernet length).

> but not to the Ethernet encapsulation?

ethernet provides message delineation, tcp does not.

> length field in the GSMP header to include vendor specific data?

sounds reasonable.

> is being used or how the API is designed.

it seems to me that it is normal that a protocol's
encapsulation in another protocol needs a specification.
since the services provided by ethernet, atm and tcp
are all different from each other, i don't see why
the respective encapsulations should not also be 
different from each other.

the tcp encaps needs a message delineation feature--the
ethernet and atm encaps do not. i don't think that
generality is good enough reason to include a redundant
message delineation feature, like the one used for tcp,
in atm and ethernet. in the same way, we use an
llc/snap header in atm, because we need to put a protocol 
type field somewhere, but not in ethernet because 
ethernet provides the protocol multiplexing feature for
us.

c u
fsb

____________________________________________________________
new adventures thursdays 7pm to 8pm on wzbc 90.3fm in boston
http://zbconline.com/ for info, streams and program archives

---

From: "Georg Kullgren" <[email-masked]>
Date: Mon, 20 Aug 2001 10:01:55 +0200

Hi

This was more or less the answer I hoped to get.
The message length field in the GSMP header will include the vendor specific
data and the encapsulation for ATM and Ethernet are unchanged.

Do we really need a byte sequence that can be used to search for the 
message boundaries in TCP. If a TCP connection is established the peers
are already synchronized. As long as the message length in the GSMP header
is correct (and no bugs in the software;-) they will stay synchronized.

> we chose this scheme of a constant

It does give an extra level of reliability since we can search for the
message boundary if synch is lost. How often does this really happen?
Often enough to validate the extra data (type,length) in the message?

If it occurs very seldom maybe it's better to reset the TCP connection
if this happens instead of sending the extra 32 bits in the encapsulation.

Are there any statistics from BGP that shows how often the marker field
actually is needed to resynchronize again?

CU
/Georg

---

From: "tom worster" <[email-masked]>
Date: Mon, 20 Aug 2001 16:05:52 -0400

From: Georg Kullgren
...
> is correct (and no bugs in the software;-) they will stay 
...
> if this happens instead of sending the extra 32 bits in the 

some form of framing is usually used to delineate the 
packets in a stream before data is given to the
next higher layer for decoding. is your suggestion 
that message delineation is handled by the application 
layer itself, i.e. by the gsmp message parser? that 
would make the framing dependent on the structure and 
redundancy of gsmp message data -- so that when a 
message is sufficiently badly garbled, the receiver 
assumes that frame sync is lost and closes the tcp 
connection. ("sufficiently badly" needs to be 
quantified, of course.)

in other words, i think you are suggest changing gsmp 
to work on a byte stream rather than on a message 
sequence (in the case of tcp encapsulation). do i 
misunderstand?

c u
fsb

---

From: "Georg Kullgren" <[email-masked]>
Date: Tue, 21 Aug 2001 11:09:55 +0200

> sequence (in the case of tcp encapsulation). do i 

Yes, that's about it.
But it's not really a suggestion, more like a question.
I'm not sure which version would be the best one in this case.

With the current draft we get a system that is more fault tolerant.
Whatever happens, we can still search for the known byte sequence to
find the next message.
On the down side we have to transmit 32 bits more in each packet.

The main question is what is the most important thing to optimize for
in this case? Reliability or packet size?

How likely is it that a message will be garbled?
We are running TCP and have retransmission and checksums on the packets.
How often will we actually need to search for a byte sequence to find a
message boundary?
If it does happen every now and then, by all means, keep the byte sequence.

I don't know the answer to this.
I just wanted to raise the question and was hoping that
someone could enlighten me :-)

CU
/Georg

---

From: "Avri Doria" <[email-masked]>
Date: Tue, 21 Aug 2001 09:05:09 -0400

"Kullgren, Georg [ERK:AA50:EXCH]" wrote:
...

> in this case? Reliability or packet size?

in terms of encapsulations, i think the answer is reliability.

a.
-- 

Avri Doria
+1 401 663 5024
===============

---

From: "tom worster" <[email-masked]>
Date: Tue, 21 Aug 2001 16:35:27 -0400

> i wrote:

> in this case? Reliability or packet size?

i certainly think that the extra 32 bits are
justified, but not primarily because they make 
the system more reliably (although they may). 
my reason is that it is good design to separate 
message delineation from semantic message parsing.

if, in the case of tcp, the gsmp message parser
is working on a byte stream then it needs to
distinguish, based on field values it sees in
that stream, between different kinds of problem: 
loss of frame errors that close the connection 
and message field value errors that do not.

firstly, such parser behaviour is inconsistent 
with the parser behaviour in the cases of atm 
and ethernet encapsulation. in these cases the
receiver should never construe value problems 
as a loss of frame sync.

secondly, separating delineation from parsing
simplifies gsmp message design since we can 
ignore the question of whether or not the 
redundancy in every gsmp message is sufficient
for the parser to discriminate loss of frame
sync from other problems. this is the biggest
issue, in my view. combining delineation and
semantic parsing forces constraints on the 
coding of gsmp messages that are difficult to 
understand or specify. design errors would be
hard to identify and to correct.

thirdly: it is traditional. while i don't 
usually like to consider myself reactionary, i 
see that there are several arguments in favour 
of following precedent in this design question.
for example, i think that the separation of 
datalink framing from the interpretation of
internetwork layer datagrams is an example
of a very successful system partitioning.

> How often will we actually need to search for a byte sequence 

there is no reasonable way to answer these 
questions. the numbers depend on many factors 
that gsmp protocol designers can neither 
predict nor control. so i don't think that we 
can resort to these quantitative arguments to 
make a design decision in this case.

it would probably be enough to note that many
protocols and applications that use tcp also
check for errors.

c u
fsb

---

From: "Georg Kullgren" <[email-masked]>
Date: Wed, 22 Aug 2001 09:56:00 +0200

Good answer.
There are TCP protocols that don't have this kind of encapsulation
that work just fine.
But that's beside the point.
You have convinced me and we can drop this question now.

CU
/Georg