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

From: [email-masked]
Date: Tue, 1 Apr 2003 08:50:24 +0000

Tom,

I agree to support the first three changes.

Tim

"tom k. johnson" <[email-masked]>
31-Mar-2003 03:14 PM

        To:     <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 27, 2003 9:40 AM
> To: [email-masked]
> Subject: RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt
> 
> 
> 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
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Tue, 1 Apr 2003 09:13:32 +0000

Yaakov,

> 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.

Actually I don't believe the IETF cares about packet sizes. Packet 
switched networks cope well with any packet size. What I am suggesting is 
that we use one of the fundamental parameters for a TDM network (i.e. 
delay) to specify how that TDM circuit is carried over the PSN. It seems 
to me that any users of this type of system will understand TDM and 
therefore will be entirely comfortable with this approach. 

> 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.

No, it is not. It is expressing the size in a metric the TDM user will 
understand, and hence doing the calculation for them. This removes 
variables such as the numbers of active timeslots and type of service from 
consideration - just pick an acceptable delay for the application.

> 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?

Well this is really coming down to the nub of the problem. Should we pick 
a complex, unnecessary pointer based mechanism to fit with a pre-existing 
implementation (TDMoIP) based on an AAL1 SAR and an ASIC, or should we 
allow the users to choose network parameters in terms that are fundamental 
to the TDM network being emulated?

We have reached the point where technical arguments don't matter any more, 
because both sides of the argument have implementations to protect. There 
have been arguments in another part of the PWE3 group recently along the 
same lines: should existing implementations be allowed to force standards?

I commend Tom Johnson for picking up the baton with draft-johnson, because 
at least he can't be criticised for trying to protect an implementation. I 
think it should now be for Tom and others outside of the immediate design 
team to suggest the way forward here. One (or both) of the "camps" will 
not like it, but it might point the way forward to a better standard.

Tim

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 1 Apr 2003 18:17:29 +0300

Tim, 

> switched networks cope well with any packet size. What I am 
> suggesting is that we use one of the fundamental parameters for a TDM network (i.e. 

If the IETF doesn't care about packet sizes,
then let's remove all mention of default sizes from the draft.

> No, it is not. It is expressing the size in a metric the TDM 
> user will understand, and hence doing the calculation for them. This removes 
> variables such as the numbers of active timeslots and type of 
> service from consideration - just pick an acceptable delay for the application.

Agreed. Let the user pick whatever size best suits the application.
This is precisely what I have been saying all along.

> Well this is really coming down to the nub of the problem. 
> Should we pick a complex, unnecessary pointer based mechanism to fit with a 
> pre-existing implementation (TDMoIP) based on an AAL1 SAR and an ASIC, or 
> should we allow the users to choose network parameters in terms that 
> are fundamental to the TDM network being emulated?

Quite the contrary.
As you well know, draft-johnson with the pointer is only
marginally helpful in allowing interworking with AAL1 networks,
and is in NO WAY related to draf-anavi.

However, draft-johnson with no pointer and frame-locking
is EXACTLY CESoPSN !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

So what you are suggesting is to throw out an obviously
useful feature - the pointer - which allows all known
applications to be supported, ONLY in order to degenerate
to a previously existing (if only marginally deployed) system.

What I am suggesting is to keep the pointer and enable
interworking with a vast number of actually deployed systems.

> because both sides of the argument have implementations to protect.

Sorry, but I don't agree.

draft-johnson is simply CESoPSN with an optional pointer.
In no way can it be seen to resemble draft-anavi.

How can you say that my insisting on a pointer is because
I want to stick to my existing implementation?
If I was insisting on having draft-anavi I wouldn't be
considering draft-johnson, with or without a pointer.

I WOULD be insisting that the header be the standard PWE header
rather than one which causes a lot of head-aches (as we have seen on the list).

I WOULD be insisting on AAL1 payloads, with the embedded sequence numbers
and pointers.

The only thing I see here is some people insisting on
a bit-exact CESoPSN draft, without even minor additions.

> There have been arguments in another part of the PWE3 group 
> recently along the same lines: should existing implementations be allowed to 
> force standards?

Absolutely not.
Especially not when we are talking about CESoPSN
which has only been marginally deployed, if at all.

> I commend Tom Johnson for picking up the baton with 
> draft-johnson, because at least he can't be criticised for trying to protect an 
> implementation. I think it should now be for Tom and others outside of the 
> immediate design team to suggest the way forward here. One (or both) of the 
> "camps" will not like it, but it might point the way forward to a better standard.

I agree that Tom did a good job, and as you know was willing to support
the effort even though it was unrelated to my system
(which has been extensively deployed).

But then the pressure was put on him to make the draft into
a CESoPSN double, at the expense of major loss of functionality.
That is when my support ended.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 1 Apr 2003 18:39:02 +0300

Tim, 

Quite the contrary.

Absolutely not.

Y(J)S

---

From: Shahram Davari <[email-masked]>
Date: Tue, 1 Apr 2003 07:42:12 -0800

Tim,

I also agree with Yaakov. If the payload size does not matter in IP networks, let's then remove the default packet sizes from all modes.

-Shahram 

>From: Yaakov Stein [mailto:[email-masked]]
>Sent: Tuesday, April 01, 2003 10:17 AM
>To: [email-masked]
>Cc: [email-masked]

---

From: [email-masked]
Date: Tue, 1 Apr 2003 15:40:20 +0000

That's true Lloyd, but nobody's suggesting that these packets are going to 
be enormous here. Perhaps to be strictly accurate I should have said 
"within limits, I don't believe the IETF cares about packet sizes."

What I am saying is that a PSN doesn't care whether all TDM packets are 
the same length, different lengths, variable lengths etc., they are just 
packets - provided they fit within the network MTU :-)

Tim

Lloyd Wood <[email-masked]>
01-Apr-2003 04:41 PM
Please respond to Lloyd Wood

        To:     [email-masked]
        cc:     Yaakov Stein <[email-masked]>, "" <[email-masked]>
        Subject:        RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt

On Tue, 1 Apr 2003 [email-masked] wrote:

> switched networks cope well with any packet size.

You may wish to read up on fragmentation, the difficulties of path mtu
discovery, jumbograms, jumboframes and superframes...

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 2 Apr 2003 12:40:38 +0200

Yaakov and all,
Please see some comments inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> Sent: Tuesday, April 01, 2003 5:39 PM
> To: [email-masked]
... snipped ...
> and is in NO WAY related to draf-anavi.
The structure pointer in draft-johnson is only marginally 
(if at all) helpful for interworking with AAL1 networks. 
I agree with that, and this is why I do not understand why it
should become mandatory.
> is EXACTLY CESoPSN !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Looks like similarity to CESoPSN is your main point of objection.
I am ready to accept this as a personal position, but not as a
technical one. 
> to a previously existing (if only marginally deployed) system.
Usefulness of this "feature" is far from obvious to me. Can you give
at least one example when using the pointer solves a provider or 
a customer problem?
... snipped ...
> which has only been marginally deployed, if at all.
Just for the record (this is NOT a technical argument!):
Interoperability of independent CESoPSN implementations
has been successfully tested between several vendors. 
In three cases this fact has been publicly announced.
... snipped to the end ...