Subject: TDM payload size in draft-johnson-pwe3-tdm-00

From: "Yaron Raz" <[email-masked]>
Date: Thu, 6 Mar 2003 08:18:05 +0200

The mandatory TDM payload sizes suggested in draft-johnson-pwe3-tdm-00 are 376 bytes for unstructured mode, and 16/24 TDM frames for structured E1/T1 respectively.

The fact that the TDM payload is that big has two negative effects:
1. The delay through the CES network is high: 24 TDM frames are 3mSec delay in the transmitter side. Then you must have at least one additional frame in the receiver jitter buffer, so you end up with at least 6mSec of delay. This may be acceptable in some applications/network scenarios, but not in others.
2. Reconstructing the TDM clock becomes more complicated. If one uses an adaptive technique, you need much more than 2 frames in your jitter buffer in order for this to work, so the delay vs. clock accuracy becomes an issue. If one uses timestamps, getting a timestamp once every 3mSec puts more constraints on the PLL mechanism, than if the receiver side got it every 1mSec or 500uSec.

My suggestion is therefore the following:
For unstructured mode, where I guess the 376 byte requirement comes from 47(AAL1 payload)x8 we reduce it to 47x3 or 47x4 (need to decide).
For structured mode, we keep the basic mode an option, but NOT a MANDATORY mode.
Alternatively, we can keep the basic structured mode but divide the TDM payload by 4 or 8 and have a running index in the header that identifies the TDM "fragment". This can even be the lsb part (2-3 lsbs) of the current sequence number.

Any thoughts?

Yaron

---

From: "tom k. johnson" <[email-masked]>
Date: Sun, 9 Mar 2003 18:10:24 -0500

Yaron - 

> -----Original Message-----
> From: Yaron Raz [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 1:18 AM
> To: PWE3 group (E-mail)
> Subject: [PWE3] TDM payload size in draft-johnson-pwe3-tdm-00
> 
> 
> The mandatory TDM payload sizes suggested in 
> draft-johnson-pwe3-tdm-00 are 376 bytes for unstructured 
> mode, and 16/24 TDM frames for structured E1/T1 respectively.

Yes, the mandatory payload sizes and formats were the most contentious
part of the draft, and subject to the most back-and-forth.  However,
it is important to note that other sizes are supported.  The mandatory
payload sizes are simply the defaults.  

> 1. The delay through the CES network is high: 24 TDM frames 
> are 3mSec delay in the transmitter side. Then you must have 
> at least one additional frame in the receiver jitter buffer, 
> so you end up with at least 6mSec of delay. This may be 
> acceptable in some applications/network scenarios, but not in others.

Definitely agree.  The question is - which scenario should we
optimize the defaults for?  Shahram and Yaakov argue that the 
key application for this sort of service is long-distance 
applications, where the propogation delays dwarf
the packetization and jitter buffer delays.  However, some of the
Metro-Ethernet oriented folks argue the reverse.  Not sure what
the right answer is, but as I noted previously - shorter packet
sizes are supported by the draft if the default delay is too long.

> 2. Reconstructing the TDM clock becomes more complicated. If 
> one uses an adaptive technique, you need much more than 2 
> frames in your jitter buffer in order for this to work, so 
> the delay vs. clock accuracy becomes an issue. If one uses 
> timestamps, getting a timestamp once every 3mSec puts more 
> constraints on the PLL mechanism, than if the receiver side 
> got it every 1mSec or 500uSec.

Yes, I can see how that could be an issue.  However, that's
not specifically a comment against the draft as a whole, but
just a question of what the defaults are, right?

> For unstructured mode, where I guess the 376 byte requirement 
> comes from 47(AAL1 payload)x8 we reduce it to 47x3 or 47x4 
> (need to decide).

I would have no problem with that.  Sasha had argued that shorter
packet sizes resulted in too much overhead relative to the payload,
but I would think everyone would be fine with something like 47x4.

(Does anybody else have a problem with that?)

> For structured mode, we keep the basic mode an option, but 

By the "basic" mode - I assume you mean the mode where the
super-frame is locked to the packet boundary (?)

> Alternatively, we can keep the basic structured mode but 
> divide the TDM payload by 4 or 8 and have a running index in 
> the header that identifies the TDM "fragment". This can even 
> be the lsb part (2-3 lsbs) of the current sequence number.

It's an interesting idea.  Of course, one of the modes of 
operation that the AAL1 camp finds useful is the ability to
set the packet size to 375 bytes, so that payload is the 
same number of bytes as an AAL1 8-cell cycle (i.e. 7x47 + 46).

So, I'm not sure how you're suggestion fits with that idea.
But, I think I get the idea.

Talk to you soon.

-Tom

> 
> Any thoughts?
> 
> Yaron
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Alik Shimelmits <[email-masked]>
Date: Mon, 10 Mar 2003 10:09:53 +0200

> mode, and 16/24 TDM frames for structured E1/T1 respectively.

please, put attention on the following: the draft defines TDM payload
size of 376 bytes for unstructured mode including E1/T1 and E3/T3.
It is attempt to provide one default for two totally different rates. And 
that's the problem. Everyone would prefer to have smaller default
for E1/T1 to provide smaller delay, let say 1ms. But in this case you
get totally meaningless value for E3/T3. I would say that 47x4 is not
a workable default for T3.

Please, notice that the default value for structured (nxDS0) is defined in
ms.
and not in bytes. That results that payload packet size in bytes varies as a
simple function of n.  That utilizes PSN capability
to work with the packets of various size oppose to ATM and
allows to keep end-2-end delay dependent only on
network characteristics (delay and jitter) and independent from
the number of DS0s in the bundle. 

I would propose to define payload size for unstructured T1/E1 and T3/E3 in
a similar way (ms) as it is defined in draft-vainshtein. Of course, in this
case you have problem with ATM-based mechanism because ATM does
not have flexibility to perform such an adjustment of packet size.

Technically, I would say, that to define TDM-PSN network interworking it 
would be better to define payload size in TDM units (frames, msec or micro)
and then calculate payload size in bytes. 

> are 3mSec delay in the transmitter side. 
... snipped
> This may be 

Agree. The problem is that if we need to define single default to ensure
interoperability. This default should provide reasonable bandwidth
effeciency for different N and reasonable delay for different applications.
The last draft-vainshtein requires the applications to support payload size
of
1, 2 and 3 ms (for n >= 4 ) in order to be complied. This is the attempt
to ensure that the implementations complied to the draft can not 
only announce interoperability but also to fit to a wider range of
applications.

With best regards
	Alik

---

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

Alik - 

I agree that it would make sense to have one default packet size for
unstructured T1/E1 and a different one for unstructured T3/E3 
(as long as the defaults are multiples of 47 bytes).

Does anyone have a problem with that?

-Tom

> From: Alik Shimelmits [mailto:[email-masked]]
> Sent: Monday, March 10, 2003 3:10 AM
> To: Yaron Raz; PWE3 group (E-mail)
> Subject: RE: [PWE3] TDM payload size in draft-johnson-pwe3-tdm-00
> 
> 
> Yaron:
>

---

From: "Yaron Raz" <[email-masked]>
Date: Tue, 11 Mar 2003 10:33:28 +0200

Tom,

First I'd like to say I think you've done a good job in finding a common ground between the approaches, one that uses the advantages of both, and still makes technical sense. The only issue I found to be of concern is the TDM payload size.
I think (like Alik) that a mandatory mode is important, and it is more than a default value. This makes different implementations interoperable.
I still suggest to reduce the TDM payload size of E1/T1 to either 3x47 or 4x47 bytes in the unstructured mode. the overhead penalty is much less, and the delay is acceptable for all applications. As far as I understand, also long-distance Internet applications do not suffer from such a payload size. For E3/T3 we can (and should) have a longer TDM payload size.
Regarding the structured mode, I believe we should have a mandatory mode there as well (although the whole mode is optional), so that if someone implements this he must conform at least to this mandatory mode. Can the AAL1 guys suggest a mode that is acceptable and still has about 3-6 x 125uS delay?

Yaron

> From: tom k. johnson [mailto:[email-masked]]
> Sent: Monday, March 10, 2003 1:10 AM

---

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

Yaron, 

> got it every 1mSec or 500uSec.

These issues were discussed at great length by the members
of the TDM DT. We all agreed that this "default packet size" is
too large for most purposes. 
In an earlier version the default size was 47.

>From my point of view 47*N with N=1 .. (some number)
is good enough. It's not clear to me why a single
size is required (unles we are trying to re-create ATM).

> For structured mode, we keep the basic mode an option, but 

What do you mean by "basic mode"?
If you mean super-frame locking should be an option
and not the only mandatory mode, I certainly agree.
This was precisely the reason I decided not to support
the final version of the draft.

BTW, if there really is a caveat for "single size" payloads,
why doesn't the default mode have a well defined size in bytes?
(It can be various sizes in bytes, depending on how many
timeslots are in use).

I would support a single packet size in bytes,
and the implementation of the header pointer mechanism
as defined in the draft.

> be the lsb part (2-3 lsbs) of the current sequence number.

There is no need for a "fragment" counter.
All you need to do is to support the
pointer which is in the draft already.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 11 Mar 2003 08:52:47 +0200

> (as long as the defaults are multiples of 47 bytes).

It seems to me that we have gone pretty far from the initial intent.

We started out looking for a single size packet.

Now we have a single size for each "mode"
where the following modes are to be defined :

  unstructured E1/T1
  unstructured E3/T3
  structured without CAS with N=1
  structured without CAS with N=2
  etc.
  structured with CAS with N=1
  structured with CAS with N=2
  etc.

(remember that if we lock onto TDM frames,
 the packet size in bytes depends on N).

Assuming we limit ourselves to 32 timeslots, 
we have a single well-defined default packet size for each
of 66 cases!

Is that really what we want?

I think that this is pretty close to using any packet size you want.

Y(J)S

> Does anyone have a problem with that?

Only those who want a single default packet size.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 11 Mar 2003 14:26:02 +0200

> First I'd like to say I think you've done a good job in 
> finding a common ground between the approaches, one that uses 
> the advantages of both, and still makes technical sense. The 
> only issue I found to be of concern is the TDM payload size.
> I think (like Alik) that a mandatory mode is important, and 
> it is more than a default value. This makes different 
> implementations interoperable.

I agree. But, as I wrote in a previous mail, 
we don't have a single mandatory mode.
We have over 60 of them.

> I still suggest to reduce the TDM payload size of E1/T1 to 
> either 3x47 or 4x47 bytes in the unstructured mode. the 
> overhead penalty is much less, and the delay is acceptable 
> for all applications. As far as I understand, also 
> long-distance Internet applications do not suffer from such a 
> payload size. For E3/T3 we can (and should) have a longer TDM 
> payload size.

> Regarding the structured mode, I believe we should have a 
> mandatory mode there as well (although the whole mode is 
> optional), so that if someone implements this he must conform 
> at least to this mandatory mode. Can the AAL1 guys suggest a 
> mode that is acceptable and still has about 3-6 x 125uS delay?

Only if there is a length field (since the AAL1 structured mode
has varying cell sizes).

Y(J)S