Subject: RE: [Monami6] Packet format: draft-soliman-monami6-flow-binding-00.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 13 Apr 2006 08:34:22 -0700

> 
 > Okay, I should have said 'hard to extent'. Sure there are a 
 > couple of 
 > bits left and room for 255 bytes altogether, but let's 
 > imagine that we 
 > end up with the proposed kind of format and then later on 
 > when people 
 > start extending the format. It will be difficult to add new fields, 
 > because there is no clean way to recognize (and skip) 
 > fields. Let's say 
 > that I write an extension called X, and someone then writes 
 > an extension 
 > called Y. Because I have already added a new field, the 
 > author of the 
 > extension Y has to also take this into account; the Y field could be 
 > after the X field. I just feel that creating such a chain of 
 > dependency 
 > is not necessarily a good characteristic of a protocol.

=> Ok, but can explain how this is different in this particular option
from any other option? These extensions you refer to would be defined
as suboptions so they're completely transparent to this option. 
Specifically, I'm hoping you could tell me the following:
How do you extend any other option in IPv6 and why is it not 
applicable here? But please tell me in detail not in an abstract manner.

 > This option is defined so that it does
 > > *not* have static alignment. I know this is different from 
 > the way we define
 > > options in IPv6, but I'd like to hear why this is really 
 > bad and whether 
 > > having a fixed option is a lot better given the huge waste 
 > we will have
 > 
 > I don't know about being really bad, but I'm sure that some 
 > experts can 
 > write a novel about why alignment is generally a good thing. 

=> Please note that the option will always be aligned, i.e. if not 
naturally, by padding. So if you're arguing for padded alignment
Vs natural alignment then please clarify that. I know there is 
a tradeoff with simplicity here, but IMO it's more important to
be radio efficient than to design for a simple implementation.
At least from a job security view point :)

  Anyway, 
 > proper alignment increases the processing speed (important 
 > for servers 
 > like the HA) and it eases the implementation task (less bugz)

=> Agreed.

 > 
 > cs = ((((char *) p->data[cs_offset])   & 0x0f) << 4) |
 >       ((((char *) p->date[cs_offset+1]) & 0xf0) >> 4);
 > 
 > instead of:
 > 
 > cs = p->data[cs_offset];

=> Sure, no disagreement here.

 > 
 > In addition, some architectures can't handle integers that 
 > don't start 
 > from their natural word boundaries, i.e.
 > 
 > flow_label = *((u16_t *) p->data[fl_offset]);
 > 
 > would crash the system.

=> I'm not sure if there is something that doesn't start
on a natural boundary here. More below.

 > 
 > The situation could be improved at least to some extend with the 
 > following re-arrangement of the fields:
 > 
 >        |                                                     
 >           |
 >        +                                                     
 >           +
 >        |                                                     
 >           |
 >        +                       Source Address                
 >           +
 >        |                                                     
 >           |
 >        +                                                     
 >           +
 >        |                                                     
 >           |
 >        
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >        |                                                     
 >           |
 >        +                                                     
 >           +
 >        |                                                     
 >           |
 >        +                    Destination Address              
 >           +
 >        |                                                     
 >           |
 >        +                                                     
 >           +
 >        |                                                     
 >           |
 >        
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >        |                            SPI                      
 >           |
 >        
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >        |     Source port               |    Destination port 
 >           |
 >        
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >        |        Flow Label             |   Protocol    |     
 > C. S.     |
 >        
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > 
 > How does that sound?

=> It looks aligned perfectly to me but it's wrong :) 
if you want this option you need to change RFC 2460 to make 
the flow label 16 bits instead of 20 :( 

Hesham

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 18 Apr 2006 10:11:38 +0300

teristic of a protocol.
> as suboptions so they're completely transparent to this option.

I was more thinking the case that someone would like to extend this 
particular suboption. Naturally defining a new suboption solves the 
case, but the reason why I'm thinking about the need to extend this 
particular suboption is that I'm trying to figure out is there something 
else needed besides the fields specified in the draft. This is of course 
only valid if all flow binding related fields should be inside the same 
suboption.

> naturally, by padding.

Of course.

> I know there is 

Well, tradeoffs are tricky...

> on a natural boundary here. More below.

You are right. The only way I see is to make the flow label easier to 
handle as an integer would be to extend it to 32 bits (in this draft).

> => It looks aligned perfectly to me but it's wrong :) 

Oops, my mistake. :|

The flow field could be extended to 24 bits but naturally only 20 bits 
would be meaningful.

  |     C. S.     |
  +-+-+-+-+-+-+-+-+

There would still be alignment issues (in the case some of the other 
fields would not be present) but at least the SPI field would be aligned 
correctly.

Extending the flow label field to 32 bits (still only using 20 bits, 
though) would also be something worth considering for:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            SPI                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Flow Label                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Source port               |    Destination port           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |     C. S.     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It would surely waste 12 bits but would solve those alignment issues in 
the given format. A tradeoff :)

 > the flow label 16 bits instead of 20 :(

Yep, we leave the RFC alone.

-- 
Tero