Subject: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 6 Mar 2003 14:22:04 +0200

Tom and all,

Following Tom's suggestion, I'd like to present a single major 
technical point of disagreement I have with 
draft-johnson-pwe3-tdm-00.txt.

The issue is the use of superframe structures in emulation of 
NxDS0 without CAS (Section 3.1.3) and its consequences.

To the best of my knowldege, superframe structures (or
their analogs) are completely irrelevant for NxDS0 without CAS. 
Please note that the superfame structures may even not exist 
in the corresponding trunk (e.g., E1 with the basic framing only). 

IMO, the only relevant structure for these services is a
single frame (as described in the appropriate section of
draft-vainshtein-cesopsn-05.txt), and the encpasulation
method should preserve only these structures. BTW, ATM-CES
(which Tom claims as the basis for his approach)
takes exactly the same position.

Hence I do not see any advantage in first inntroducing superframe
structures where they do not belong and then investing effort
in preserving them across the PSN. On the other hand, 
I see definite disadvantages in this approach:

1. It makes extension of the service to N > 31 complicated
   (should it be treated as T1-NxDS0 or E1-NxDS0)?

2. It prevents using the "packet-locked structures" mode
   (i.e., pointer = 0) anywhere beyond the default mode.
   While such a limitation seems reasonable for NxDS0 with
   CAS (because the structures in case are not homogeneous), 
   I do not see any reason to prohibit it for NxDS0
   without CAS. draft-johnson correctly mentions that
   non-default modes should be supported in order to allow
   trade-off between BW efficiency and packetization latency.

3. It makes handling of lost packets more complicated. In
   particular, I would expect that loss of a short packet
   could easily result in loosing the entire superframe
   structure. (The draft simply does not define handling 
   of lost packets, but doing something else would be tricky,
   and, AFAIK, incorrect in case of non-Voice payload).

4. It is incompatible with ATM-CES. Since such a compatibility 
   has been claimed as one of the objectives of the draft, 
   I see this as a case of internal inconsistency.

5. It results in unnecessary proliferation of service types
   (T1-NxDS0 is incompatible with E1-NxDS0).

I am absolutely convinced that the usage of a TDM frame
as the basic structure to be preserved across the PSN is the 
only correct technical approach for NxDS0 without CAS 
(as defined in ATM-CES and in the CESoPSN draft). 

I have discussed this issue privately with Tom and
also on the TDM Design Team mailing list, but I failed to
convince him that a change is necessary. 

While there are other minor items (both technical and 
editorial) where, in my opinion, some changes in 
draft-johnson are justified, the artificial superframe 
structure for NsDS0 without CAS remains the major problem 
preventing me from supporting this draft.
With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: tom k. johnson [mailto:[email-masked]]
> Sent: Saturday, March 01, 2003 2:30 AM
> To: [email-masked]
> Subject: RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt
> 
... snipped ...
> 
> I'm sure the interested parties will be happy to point out 
> the aspects of the draft that they do not agree with :-) 
... snipped to the end ...

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 6 Mar 2003 19:26:47 +0200

Yaakov, Tom and all,
Please see some comments inline.

With best regards,
                                   Sasha Vainshtein

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 4:14 PM
> To: Sasha Vainshtein; tom k. johnson; [email-masked]
> Sasha, 
... snipped ...
> 
> Once again, to clarify your point,
> the only relevant structure WITHOUT CAS
> is the frame. Indeed, ATM-CES differentiates
> between the "structured" and the "structured with CAS"
> cases. In the former case the pointer points
> to the beginning of the frame, while in the latter
> it is to the beginning of the superframe.
>
Exactly.
... snipped ...
> <snip>
> While I agree with the problems you raise,
> I believe that they are mostly due to not implementing
> the pointer mechanism as defined in the draft.
> 
> Try using some reasonable packet size (e.g. 128 bytes)
> and the pointer - do these problems still persist?
>
.snipped ...
> 
> In my opinion, the single major problem
> is not making the pointer mechanism MANDATORY.
> By doing so all the problems you mention
> go away.
>
I think that the pointer mechanism solves one and only
one problem: decoupling between the structure size and
the packet payload size. It surely would not transform
an irrelevant structure (superframe for NxDS0 without CAS)
into a relevant one. 
I believe that decoupling mentioned above is meaningful
for trunk-specific NxDS0 with CAS because the structure
in question takes 2 or 3 milliseconds to packetize and
is non-homogeneous (comprises the TDM payload
and signaling substructures).
For NxDS0 with CAS the REAL structures are very short (N octets)
and take just 125 microseconds to packetize. Hence 
using the packet payload size that is a multiple of the 
structure size solves all the problems at zero cost.
In particular, handling of lost packets is trivial.
> Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Fri, 7 Mar 2003 00:06:23 +0200

Tom,

My opinion:

The draft handles well the unstructured and N*DS0 with CAS services. The
draft uses CEP header and encapsulations aligned with SONET CEP, which
is also great. It provides a simple yet robust encapsulation to these
services.

Yet, I do agree with the basic comment regarding the N*DS0 without CAS.

There is no justification to force super-frame structure on a service
that does not have any.

Which super-frame structure, E1 or T1, should be forced on a video
conference application using 256kbit/sec?

The only structure common to all TDM services is the 125us frame. I
therefore suggest to remove the super-frame structure and use 125us
frame structure instead for N*DS0 without CAS.

Thanks
Ron

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sasha Vainshtein
> Sent: Thursday, March 06, 2003 7:27 PM
> To: 'Yaakov Stein'; tom k. johnson; [email-masked]
> For NxDS0 with CAS the REAL structures are very short (N 
> octets) and take just 125 microseconds to packetize. Hence 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
>

---

From: "Uri Rotshtein" <[email-masked]>
Date: Mon, 10 Mar 2003 13:15:38 +0200

Sasha, 
I agree with your objection to draft-johnson wrt NxDS0 without CAS: 
there is neither need nor justification for superframe structures 
in emulation of these services. Its usage in draft-johnson-pwe3-tdm-00.txt 
looks like a "copy and paste" bug from NxDS0 with CAS. 
In fact, the two services are different: the latter deals only with 
a bundle of independent Voice channels, while the former 
may be used for different purposes (including Voice). 
Hence the reuse, if at all possible, should work the 
other way round: from a solution for NxDS0 without CAS 
to a solution for NxDS0 with CAS. The latest CESoPSN draft 
describes such an approach while leaving place for 
dedicated solutions for NxDS0 with CAS as well. 
I think that the method based on preservation of frames across the 
PSN (e.g. as it is described in draft-vainshtein-cesopsn-05.txt) is 
the correct solution for NxDS0 without CAS. 
Regards,  Uri.

---

From: "tom k. johnson" <[email-masked]>
Date: Mon, 10 Mar 2003 08:20:19 -0500

Thanks Uri

I was trying to address two unrelated problems with a single mode of operation, but
it seems pretty clear now that the default text for NxDS0 w/o CAS needs a little
rework.  

I'll try to put together some alternative text prior to the meeting in San Francisco
and post it to the list.

Thanks

-Tom

> From: Uri Rotshtein [mailto:[email-masked]]
> Sent: Monday, March 10, 2003 6:16 AM
> To: [email-masked]; [email-masked]

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 6 Mar 2003 16:13:51 +0200

Sasha, 

> in the corresponding trunk (e.g., E1 with the basic framing only). 

I think that you state it a trifle to harshly
since the CRC sync structure may be of interest,
but only in very isoteric instances.

On the whole I agree, that the superframe structure
is only important when there is CAS, or some
other superframe-based signaling.

> in preserving them across the PSN. 

I agree - so why don't we agree on the ATM-CES
approach of differentiating between the with
and without CAS cases?

<snip>

Y(J)S

---

From: [email-masked]
Date: Wed, 26 Mar 2003 11:25:37 -0000

Yaakov Stein wrote 06 March 2003 14:14
<snipped>
> other superframe-based signaling.
NH=>The main reason CRC4 was introduced in the E1 frame structure was to
prevent false framing on a persistent facsimile of the FAS (Frame Alignment
Signal) appearing in the time-slots.  Not a problem with voice, but
persistent data patterns can create FAS mimics (either wholly within 1 slot
or across a pair of slots).

regards, Neil

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 26 Mar 2003 14:46:04 +0200

> NH=>The main reason CRC4 was introduced in the E1 frame 
> structure was to prevent false framing on a persistent facsimile of the FAS 
> (Frame Alignment Signal) appearing in the time-slots.  Not a problem with voice, but
> persistent data patterns can create FAS mimics (either wholly 
> within 1 slot or across a pair of slots).

Neil, 

Thanks for the clarification.

The question we were refering to is
whether there are applications that require
the phase of the timeslot in the super frame
to be preserved.

Obviously when there is CAS the superframe phase
is important, but our E1/T1 cross-connects
do not preserve the superframe structure even then,
but rather recreate a new superframe at the output.
I have heard of cases where this is problematic,
but I believe in general this is a reasonable thing to do.

Hence the question as to the requirement to 
maintain superframe structure in the CAS-less case.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 26 Mar 2003 15:33:24 +0200

Neil, Yaakov and all,
Please see some comments/questions inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, March 26, 2003 2:46 PM
> To: [email-masked]; Sasha Vainshtein;
> [email-masked]; [email-masked]
IMO this particular problem is irrelevant wrt emulation of structured
TDM over PSN (the scope of this email thread) because all the approaches 
I am aware of (including draft-johnson) assume that FAS and CRC4 are 
stripped from the E1/T1 attachment circuit at ingress and reconstructed 
at egress and, what is more, stripping and reconstruction is always done
by an NSP block (= TDM framer). 
> but rather recreate a new superframe at the output.
My understanding too.
> but I believe in general this is a reasonable thing to do.
IMO, TR NWT 170 explicitly allows this for T1 by specifying
different limits for delay on TDM data (700 microseconds)
and CAS (5 milliseconds).
> maintain superframe structure in the CAS-less case.
I think that Yaakov has correctly presented the question. 
However, I would like to add that, AFAIK, multiframe structure
and CRC4 are not mandatory for E1 trunks because 
G.704 explicitly states that bit Si (carrying the MF alignment and
CRC4) can be set to 1 in all frames "if no use is realized".
In other words, in the CAS-less case there may be no native multiframes
to preserve over the PSN. Is this understanding correct?

---

From: [email-masked]
Date: Thu, 27 Mar 2003 14:39:36 +0000

I have noted the following main comments on draft-johnson over the last 
month, both on the list and at the San Francisco meeting:

1. The default payload size for unstructured E1/T1 is too large at 376, 
this should be reduced to 141 (47*3) or 188 (47*4).
Since other payload sizes may be supported at will, I don't anticipate any 
significant objection to this.

2. The default payload size for unstructured E3/T3 should be separated 
from that for E1/T1. It could remain at 376.
This seems reasonable to me.

3. The use of a superframe format for NxDS0 without CAS is unjustified
I think everyone on the list agrees with this point. We seem to be in 
agreement that the only relevant structure is the 125us frame.

4. The structure pointer mechanism for NxDS0 with/without CAS should be 
made mandatory
This is the main point of controversy.

One of the main benefits of the pointer mechanism is to make interworking 
with AAL1 CES easier. AAL1 CES delivers cells with no fixed relationship 
to the frame structure, but with a pointer to identify where that 
structure starts. Therefore these cells may be received by an 
inter-working function, the ATM and AAL1 header bytes stripped, and the 
cells placed into a packet, with the AAL1 structure pointer modified as 
required to point to the first occurence of the frame structure within the 
packet. 

AAL1 required a pointer mechanism because the cell size was fixed. 
Therefore it was not possible to vary the size of the payload with the 
value of N, or to suit the application. In fact the payload size varies 
with the addition of the pointer in every eighth cell.

A packet switched network on the other hand copes with a wide range of 
packet sizes. This allows signficant possibilities, such as specifying the 
packet size in terms of packetization delay, e.g. packet size = N * number 
of frames delay required. This is important, since a key attribute of TDM 
systems is the overall latency, of which the packetization delay may be a 
signficant component  in many applications. It also allows the delay to be 
kept constant regardless of the value of N, which is an important 
consideration for service providers who may be providing fractional T1 
service with different values of N to different customers, but keep the 
latency budget the same for each customer.

If the packet size is defined in this way, the structure pointer is no 
longer required. This is because the packet size is now locked to the TDM 
frame boundary, simplifying the construction of the header.

Therefore the question comes down to what Shahram expressed at the San 
Francisco meeting: What is most important, the ability to define 
packetization delay that is constant with N , or making inter-working with 
AAL1 services easier?

As we requested at the San Francisco meeting, please express your 
arguments to the list.

Cheers,
Tim

---

From: Shahram Davari <[email-masked]>
Date: Thu, 27 Mar 2003 07:17:26 -0800

Tim,

Excellent summary of the issues. I support all 4 points that you raised. 

Regarding point 4, I prefer ease of interworking with ATM CES. The reason is that if pointer is not supported, then it becomes impossible to interwork with ATM CES, without first converting the TDM emulated packets to TDM and then converting it back to ATM CES. However,
I don't think adding a pointer to the header complicates the protocol that much. Also if the
pointer is present then off course constant delay for every N could also be achieved. So I think mandating the pointer solves 2 problems:

a) Ease of interworking with ATM CES
b) Constant delay regardless of N

Yours,
Shahram

>From: [email-masked] [mailto:[email-masked]]
>Sent: Thursday, March 27, 2003 9:40 AM
>To: [email-masked]

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 30 Mar 2003 14:49:13 +0300

> 1. The default payload size for unstructured E1/T1 is too 
> large at 376, this should be reduced to 141 (47*3) or 188 (47*4).
> Since other payload sizes may be supported at will, I don't 
> anticipate any significant objection to this.

I think many would prefer 188, to keep it a multiple of 32 bits.
However, perhaps we do not require a default length at all.

> 2. The default payload size for unstructured E3/T3 should be 
> separated from that for E1/T1. It could remain at 376.

Once again, we should allow the use of any convenient packet size.

> agreement that the only relevant structure is the 125us frame.

That is the most relevant TDM structure,
and thus there should be a requirement for the pointer
in draft-johnson to point to it.
However, there is no reason for the packet size to be constrained to this length.

> 4. The structure pointer mechanism for NxDS0 with/without CAS 
> should be made mandatory This is the main point of controversy.

Agreed.

> One of the main benefits of the pointer mechanism is to make 
> interworking with AAL1 CES easier. AAL1 CES delivers cells with no fixed 
> relationship to the frame structure, but with a pointer to identify where that 
> inter-working function, the ATM and AAL1 header bytes 
> stripped, and the cells placed into a packet, with the AAL1 structure pointer 
> modified as required to point to the first occurence of the frame 
> structure within the packet. 

As you state, this is ONE benefit,
but it is certainly not the only one.
The TDM DT expended a truly enormous effort
at trying to reach a single default packet size.
This caused difficulties, due to different services
requiring different overhead-latency trade-offs.
Using the pointer allows one to arbitrarily set the packet size,
and still maintain TDM frame (or CAS multiframe, as the case may be)
integrity.

> Therefore it was not possible to vary the size of the payload 
> with the  value of N, or to suit the application. In fact the payload 
> size varies with the addition of the pointer in every eighth cell.
> 
> A packet switched network on the other hand copes with a wide 
> range of packet sizes. 

Agreed. So why do you insist on locking the packet size to
the frame length, by making the pointer optional.
This effectively makes IP packets into fixed length cells.

> This allows signficant possibilities, such as 
> specifying the packet size in terms of packetization delay, e.g. packet size 
> = N * number of frames delay required. This is important, since a key 
> attribute of TDM systems is the overall latency, of which the packetization 
> delay may be a signficant component in many applications. It also allows 
> the delay to be kept constant regardless of the value of N, which is an important 
> service with different values of N to different customers, 
> but keep the latency budget the same for each customer.

This has been discussed at great length in the TDM DT.
No explanation of why different PWs carrying different numbers
of timeslots should have precisely equal latencies
has ever been proffered. 

And in any case, by implementing the pointer
any convenient packet size can be used,
making this entire argument meaningless.

> If the packet size is defined in this way, the structure 
> pointer is no longer required. This is because the packet size is now 
> locked to the TDM frame boundary, simplifying the construction of the header.

As I have stated in the past, defining an IP packet size
in microseconds is entirely opaque to the IETF.
Packet sizes have to be stated in bytes.
What you are suggesting is an elaborate scheme for
selecting a default packet size in bytes, based
on TDM frames, numbers of active timeslots, 
type of service (E1, T1, E3, T3), etc.
Not only is this scheme extremely confusing
when presented in IETF terms, it is not required.
Just implement the pointer
and allow the user to pick any size he likes!
 
> Therefore the question comes down to what Shahram expressed 
> at the San Francisco meeting: What is most important, the ability to define 
> packetization delay that is constant with N , or making 
> inter-working with AAL1 services easier?

No, the question is - should one define an elaborate
scheme to force a packet size to agree with that of 
a pre-existing implementation (CESoIP), or should
one allow users to use the packet size that best fits
their requirements?

Those requirements may be CES-interworking,
or may be low-latency (as for metro networks), 
or may be large packets (as for wireless networks).
 
Y(J)S

---

From: "tom k. johnson" <[email-masked]>
Date: Mon, 31 Mar 2003 09:14:20 -0500

Tim - 

Thanks for the excellent summary of issues.  

I would support the first three changes that you suggest for sure.

The 4th item (as you've noted) continues to be the key point of contention.  

I personally would support making the use of the pointer mandatory, but I certainly understand and appreciate the arguments to the contrary...

Perhaps at a minimum we could all agree on the first the modifications (?)

Thanks

-Tom

> large at 376, 
> separated 
> should be 
> interworking 
> stripped, and the 
> with the 
> range of 
> but keep the 
> pointer is no 
> at the San

---

From: Alik Shimelmits <[email-masked]>
Date: Mon, 31 Mar 2003 20:48:14 +0200

Tom and all,
 
can someone, please, present real engineering consideration about
interworking with 
ATM-CES, i.e. actually how this interworking should operate. At least, to
give minimal 
guidelines for handling of lost and mis-ordered cells, as a minimum for
unstructured services 
(where it supposed to be "clear to everyone").

Regards
	Alik