Subject: RE: [PWE3] CW sequence number (was length)

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 8 May 2005 12:32:05 +0200

> My preference  is that there will be only one option: Use the 
> entire sequence number set without skipping zero. The skip 
> zero is a wrong design choice. It should be defined that if 
> sequence numbers are not used, the sequence number must be 
> set to zero. Otherwise all sequence numbers must be used. 
> Apart from the fact that some might have implemented this, 
> what is the benefit of skipping zero?
> 
> I would at least first ask who has strong objections to the 
> above. Only if compromise must be taken I would choose (a). 

Ron, 

Although, as you well know, I also use SNs,
I do understand the argument for skipping zero
for cases where SNs may be optional.

It allows the egress IWF to determine from the packet itself
that the SN is not being used. You may recall the thread a while back
on "PWE chips", where we discussed the issues of IWF state 
vs. self-description in the packet.
While many were worried about too much self-description
(since that would infer that we would always have to check)
that argument does not hold for the SN, as that is always checked.

So unless we decide to make SNs mandatory,
I still see usefulness to the skipping of zero strategy.

Hence my compromise (as expressed before)
skip zero for all encaps where the SN is optional,
and don't for all encaps where it is mandatory.

Y(J)S

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

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Sun, 8 May 2005 11:02:26 -0700

> Ron, 
> 
> Although, as you well know, I also use SNs, I do understand 
> the argument for skipping zero for cases where SNs may be optional.
> 
> that the SN is not being used. You may recall the thread a 
> while back on "PWE chips", where we discussed the issues of 
> IWF state vs. self-description in the packet.
> So unless we decide to make SNs mandatory, I still see 
> usefulness to the skipping of zero strategy.
> 
> Hence my compromise (as expressed before) skip zero for all 
> encaps where the SN is optional, and don't for all encaps 
> where it is mandatory.
> 
> Y(J)S
> 

Yaakov,

Even for encap types that mandate SN, such as ATM, there is still
usefulness in supporting skipping zero.  For example, ATM OAM cells
can be sent with SN zero even sequencing is enabled for data traffic.
This can make sure that the peer PE will never drop OAM cells even for
the ones that arrive out-of-order.  In general, skipping zero provides
a way for non-sequencing sensitive data to flow in band with sequencing
sensitive data.  

Maria Alice

---

From: [email-masked]
Date: Sun, 8 May 2005 13:57:28 -0500

Maria, Yaakov,

I do not see any advantage in skipping zero. 

Yaakov, I don't understand your point.
Suppose I have two PEs, one configured to use sequence numbers and the other not. What does it matter if the PE which uses sequence number skips zero or not? Surely more than one packet is going to be sent this direction, so regardless if one packet has the zero value, the following 65535 packets will have sequence numbers different from zero. On the other direction, the PE which expects to get packets with sequence numbers would identify that it is missing 65535 packets each cycle. Its not rocket science to figure out on this end too that the configuration is wrong.

And in general there are many parameters that needs to be agreed upon between two PEs. Use of header or not, service type, use of sequence number, etc. All these are done with once the circuit is setup using LDP or similar protocol. I don't see any advantage in selecting one parameter, especially one that breaks the common implementation of sequence number processing IWFs supporting multiple services. 

I don't fully understand Maria's point either. The IWF differentiate the OAM packets from data packets and can treat it with what ever policy it likes. The sequence numbers (or lack of) of OAM packets are not related to the sequence number of data packets. It is a strange design choice to send sensitive data without sequencing information, especially if you want to understand you lost one packet on the way.    

Ron
Resolute Networks
Redux and Lycium Unite

----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maria A. Dos Santos (mariados)
Sent: Sunday, May 08, 2005 11:02 AM
To: [email-masked]; [email-masked]
Subject: RE: [PWE3] CW sequence number (was length)

Yaakov,

Even for encap types that mandate SN, such as ATM, there is still usefulness in supporting skipping zero.  For example, ATM OAM cells can be sent with SN zero even sequencing is enabled for data traffic. This can make sure that the peer PE will never drop OAM cells even for the ones that arrive out-of-order.  In general, skipping zero provides a way for non-sequencing sensitive data to flow in band with sequencing sensitive data.  

Maria Alice

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Sun, 8 May 2005 16:17:05 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, 8 May, 2005 11:57
> To: [email-masked]; Maria A. Dos Santos (mariados); [email-masked]
> Suppose I have two PEs, one configured to use sequence 
> numbers and the other not. What does it matter if the PE 
> which uses sequence number skips zero or not? Surely more 
> than one packet is going to be sent this direction, so 
> regardless if one packet has the zero value, the following 
> 65535 packets will have sequence numbers different from zero. 
> On the other direction, the PE which expects to get packets 
> with sequence numbers would identify that it is missing 65535 
> packets each cycle. Its not rocket science to figure out on 
> this end too that the configuration is wrong.
> 
> And in general there are many parameters that needs to be 
> agreed upon between two PEs. Use of header or not, service 
> type, use of sequence number, etc. All these are done with 
> once the circuit is setup using LDP or similar protocol. I 
> don't see any advantage in selecting one parameter, 
> especially one that breaks the common implementation of 
> sequence number processing IWFs supporting multiple services. 
> 
> I don't fully understand Maria's point either. The IWF 
> differentiate the OAM packets from data packets and can treat 
> it with what ever policy it likes. The sequence numbers (or 
> lack of) of OAM packets are not related to the sequence 

For an ATM AAL5 circuit, both OAM cells and data packets are sent
thru the pw the same way, and they share the same sequence number
space.  Why are they not related?

> number of data packets. It is a strange design choice to send 
> sensitive data without sequencing information, especially if 
> you want to understand you lost one packet on the way.    

Ron, I didn't mean to jump into this thread without much background
of the whole conservation.  But please bare with me a bit and please
back track a little.

Are you proposing to change the behavior described in section

3.1.2. Processing the sequence number

in the draft-martini-l2circuit-encap-mpls-09.txt draft?

"- if the sequence number on the packet is 0, then the packet passes
       the sequence number check"

For an ATM aal5 circuit over an atom pw, the traffic that passes through
the pw could be ATM cells or an AAL5 CPCS-SDUs.  The AAL5 SDUs are
sequencing
sensitive.  But it makes perfect sense to send over OAM cells without
sequencing number, so they will never be dropped by the peer because
of sequencing errors and thus avoid potential circuit flapping.

Today, we can achieve this requirement by using 0-seqnum for the OAM
cells.  The receiving PE needs a way to decide whether the received
frame should be subject to sequencing out-of-order detection/treatment 
(i.e. drop).

In the martini draft today, there is no SEQ indication in the CW flag
bits.
And thus we need the 0-seqnum for that purpose.  I can see that the T
bit
defined for the "ATM AAL5 CPCS-SDU Mode" can be used for that purpose,
and
thus freeing the 0-seqnum back into the sequence number space.

Would you please point me to the document that fully describes your
proposal?
I would like to understand it more.

thanx for the response,
Maria Alice

> > Although, as you well know, I also use SNs, I do understand the 
> > argument for skipping zero for cases where SNs may be optional.
> > 
> > It allows the egress IWF to determine from the packet 
> itself that the 
> > SN is not being used. You may recall the thread a while 
> back on "PWE 
> > chips", where we discussed the issues of IWF state vs. 
> > self-description in the packet.
> > While many were worried about too much self-description (since that 
> > would infer that we would always have to check) that 
> argument does not 
> > hold for the SN, as that is always checked.
> > 
> > Hence my compromise (as expressed before) skip zero for all encaps 
> > where the SN is optional, and don't for all encaps where it is 
> > mandatory.
> > 
> > Y(J)S
> > 
> 
> Yaakov,
> 
> Even for encap types that mandate SN, such as ATM, there is 
> still usefulness in supporting skipping zero.  For example, 
> ATM OAM cells can be sent with SN zero even sequencing is 
> enabled for data traffic. This can make sure that the peer PE 
> will never drop OAM cells even for the ones that arrive 
> out-of-order.  In general, skipping zero provides a way for 
> non-sequencing sensitive data to flow in band with sequencing 
> sensitive data.  
> 
> Maria Alice
>

---

From: [email-masked]
Date: Sun, 8 May 2005 22:15:46 -0500

Maria Alice,

I'm no expert in ATM emulation. I don't have an alternate proposal ready. Thanks for your explanation about OAM and data multiplexing in ATM emulation.

For argument sake, if I had to design ATM emulation from scratch, I would have used a multipelxing bit to differentiate between OAM and data packets. Packets with OAM bit set would not be dropped even if misordered. Data packets received out of order would be dropped. 

Following this discussion and other feedback on the list, I don't see much point in further discussing this. It was demonstrated that its too late for changes.

Best regards
Ron

> lack of) of OAM packets are not related to the sequence 

For an ATM AAL5 circuit, both OAM cells and data packets are sent thru the pw the same way, and they share the same sequence number space.  Why are they not related?

> you want to understand you lost one packet on the way.    

Ron, I didn't mean to jump into this thread without much background of the whole conservation.  But please bare with me a bit and please back track a little.

For an ATM aal5 circuit over an atom pw, the traffic that passes through the pw could be ATM cells or an AAL5 CPCS-SDUs.  The AAL5 SDUs are sequencing sensitive.  But it makes perfect sense to send over OAM cells without sequencing number, so they will never be dropped by the peer because of sequencing errors and thus avoid potential circuit flapping.

Today, we can achieve this requirement by using 0-seqnum for the OAM cells.  The receiving PE needs a way to decide whether the received frame should be subject to sequencing out-of-order detection/treatment 
(i.e. drop).

In the martini draft today, there is no SEQ indication in the CW flag bits. And thus we need the 0-seqnum for that purpose.  I can see that the T bit defined for the "ATM AAL5 CPCS-SDU Mode" can be used for that purpose, and thus freeing the 0-seqnum back into the sequence number space.

Would you please point me to the document that fully describes your proposal? I would like to understand it more.

thanx for the response,
Maria Alice

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 9 May 2005 08:55:30 +0200

Ron, Maria and all,
Please see a few brief comments inline.
Basically I agree with Andy and Stewart that it is
too late to change the sequencing mechanisms.

Regards,
					Sasha Vainshtein
email:				[email-masked]
phone:				+972-3-7659993 (office)
mobile:				+972-52-674833

> Sent: Monday, May 09, 2005 5:16 AM
> To: [email-masked]
> Cc: [email-masked]
> I'm no expert in ATM emulation. I don't have an alternate 
> proposal ready. Thanks for your explanation about OAM and 
> data multiplexing in ATM emulation.
> 
> For argument sake, if I had to design ATM emulation from 
> scratch, I would have used a multipelxing bit to 
> differentiate between OAM and data packets. 
>
[Sasha] This is exactly what the T-bit is for in the current
encapsulation. And it has been introduced (in addition to 
the original Martini draft) exactly for this purpose.
>
> Packets with OAM 
> bit set would not be dropped even if misordered. Data packets 
> received out of order would be dropped. 
>
[Sasha] Data packets received out of order could be also
reordered (at a price). 
> 
> Following this discussion and other feedback on the list, I 
> don't see much point in further discussing this. It was 
> demonstrated that its too late for changes.
> 
> Best regards
> Ron
> 
> 
> 
> For an ATM AAL5 circuit, both OAM cells and data packets are 
> sent thru the pw the same way, and they share the same 
> sequence number space.  Why are they not related?
> 
> Ron, I didn't mean to jump into this thread without much 
> background of the whole conservation.  But please bare with 
> me a bit and please back track a little.
> 
> For an ATM aal5 circuit over an atom pw, the traffic that 
> passes through the pw could be ATM cells or an AAL5 
> CPCS-SDUs.  The AAL5 SDUs are sequencing sensitive.  But it 
> makes perfect sense to send over OAM cells without sequencing 
> number, so they will never be dropped by the peer because of 
> sequencing errors and thus avoid potential circuit flapping.
> 
> Today, we can achieve this requirement by using 0-seqnum for 
> the OAM cells.  
[Sasha] Not dropping out-of-order OAM cells is one thing.
Forcing the receiver to ignore their order and/or the fact
that they have been re-ordered is something else. 
The native ATM OAM mechanisms could be possibly corrupted
(since they assume that cells are NOT reordered on a link).
>
> The receiving PE needs a way to decide 
> whether the received frame should be subject to sequencing 
> out-of-order detection/treatment 
> (i.e. drop).
> 
> In the martini draft today, there is no SEQ indication in the 
> CW flag bits. And thus we need the 0-seqnum for that purpose. 
>  I can see that the T bit defined for the "ATM AAL5 CPCS-SDU 
> Mode" can be used for that purpose, and thus freeing the 
> 0-seqnum back into the sequence number space.
>
[Sasha] Again, it has been introduced exactly for that purpose.
> 
> Would you please point me to the document that fully 
> describes your proposal? I would like to understand it more.
> 
> thanx for the response,
> Maria Alice
> 
> 
>