Subject: AW: AW: [Tsvwg] Re: SCTP PAD chunk

From: "Meyknecht, Bernward" <[email-masked]>
Date: Mon, 10 Apr 2006 12:30:12 +0200

Hi Randy,

usage of the supported chunk types parameter sounds 
perfect to me and allows for nearly anything 
with the new PAD...
also for that what Mark likes to have.

Bernie

-----Ursprüngliche Nachricht-----
Von: Randall Stewart [mailto:[email-masked]] 
Gesendet: Montag, 10. April 2006 11:56
An: Meyknecht, Bernward
Cc: Michael Tuexen; [email-masked]; [email-masked]
Betreff: Re: AW: [Tsvwg] Re: SCTP PAD chunk

Bernward:

Yes, this is a real concern I have about putting a
pad chunk between two data chunks... I am not
to sure that implementations will support this... not
that they should not.. but it is something that we must
use care if we define this new chunk...

If we make it able to go anywhere.. then maybe a restriction
on not sending it unless your peer announces support
for it... with the supported chunk types parameters... this
would then make it so an implemenation would say.. yes I
support this.. and in so doing .. say it may fall anywhere
in the packet.

Michael, what do you think?

R

Meyknecht, Bernward wrote:
> Hi all,
> 
> only one remark: please ensure that the introduction/usage of PAD 
> is compatible with all existing implementations,
> thinking e.g. about the thing with control chunks following a
> DATA chunk.
> Even a test at an interop will only give you a hint, what could
> happen, since not all implementations may take part or 
> there are 'older' code versions deployed, not being 
> tested at the interop.
> 
> Kind regards,
> 
> Bernward
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Michael Tuexen [mailto:[email-masked]] 
> Gesendet: Samstag, 8. April 2006 00:05
> An: [email-masked]
> Cc: Randall Stewart; [email-masked]
> Betreff: Re: [Tsvwg] Re: SCTP PAD chunk
> 
> Dear all,
> 
> all SCTP implementations consider only DATA chunks (ie chunks with  
> chunk type == 0)
> as data chunks and all others as control chunks. This is also what  
> RFC 2960 states and
> I think we should not change that.
> 
> Looking at the point Mark raises of aligning data not only to 32 bits  
> but possibly also to
> 64 or even 128 bits, I think this is not only relevant inside the  
> kernel but also on
> the kernel/user land. Having in mind that the DATA chunk header is 16  
> bytes (128 bits)
> the padding can be done at the application layer layer. At the  
> transport layer only
> an initial padding before the DATA chunks may be required, which is  
> possible with the
> PAD chunk.
> 
> Best regards
> Michael
> 
> On Apr 7, 2006, at 11:41 PM, Brian F. G. Bidulock wrote:
> 
> 
>>Mark,
>>
>>Mark Butler wrote:                         (Fri, 07 Apr 2006 15:24:35)
>>
>>-X--snip--X-
>>
>>>Speaking of what things are good for - what is the point of the  
>>>control
>>>chunk before data chunk rule anyway?  It has little or no  
>>>advantages -
>>>the primary effect of the rule is to increase implementation  
>>>complexity
>>>and the number of packets that have to be transmitted.
>>
>>Well, I found the rule afforded the reverse: that it decreases  
>>implementation
>>complexity and allows for processing optimizations.  Control chunks  
>>other than
>>SACK are rare during data transfer phase, whereas DATA chunks are  
>>not.  Only
>>one SACK normally occurs in a packet.  Placing the SACK in the  
>>first chunks
>>locates it nicely and a hard loop on DATA chunks can be performed  
>>after that.
>>Placing the SACK ahead of all the DATA chunks allows data buffers  
>>in the
>>retransmission buffer to be cleared before allocating any for the  
>>received
>>data chunks.
>>
>>Ask yourself the reverse question: what's the good in burying a  
>>control chunk
>>in the middle of a bunch of data chunks?
>>
>>Why not just make the padding chunk a "data" chunk.
>>
>>--brian
>>
>>-- 
>>Brian F. G. Bidulock
>>[email-masked]
>>http://www.openss7.org/
> 
>>
> 

-- 
Randall Stewart
ITD - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)