Subject: ATM/Ethernet/Control drafts minor corrections

From: Luca Martini <[email-masked]>
Date: Tue, 25 Nov 2003 10:53:14 -0700

WG members,

I have collected all the comments on the atm and ethernet  
encapsulation, drafts, as well as the control and maintenance protocol 
draft.
Most are either spelling , punctuation, or english corrections which are 
not significant enought to spell out individually.
But there is a minor text clarification below that does not change the 
technical design , but makes the reading easier.

First , the title of the ATM draft does not fit:

Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS 
Networks
So has chaged to :
Encapsulation Methods for Transport of ATM Over IP and MPLS Networks

To fit in 72 columns.

In the sequnce section:

BEFORE:
4.3.4. Processing the sequence number field in the control word
[snip]
When a packet is received on that emulated VC, the sequence number
   should be processed as follows:

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

     - otherwise if the packet sequence number >= the expected sequence
       number and the packet sequence number - the expected sequence
       number < 32768, then the packet is in order.

     - otherwise if the packet sequence number < the expected sequence
       number and the expected sequence number - the packet sequence
       number >= 32768, then the packet is in order.

     - otherwise the packet is out of order.

   If a packet passes the sequence number check, or is in order then, it
   can be delivered immediately. If the packet is in order, then the
   expected sequence number should be set using the algorithm:

   expected_sequence_number := packet_sequence_number + 1 mod 2**16
   if (expected_sequence_number = 0) then expected_sequence_number:= 1;

   Packets which are received out of order MAY be dropped or reordered
   at the discretion of the receiver.

   If a router PE2 does not support receive sequence number processing,
   then the sequence number field MAY be ignored.

AFTER:

4.3.4. Processing the sequence number field in the control word
[snip]
 When a packet is received on that emulated VC, the sequence number
   should be processed as follows:

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

     - otherwise if the packet sequence number >= the expected sequence
       number and the packet sequence number - the expected sequence
       number < 32768, then the packet is in order.

     - otherwise if the packet sequence number < the expected sequence
       number and the expected sequence number - the packet sequence
       number >= 32768, then the packet is in order.

     - otherwise the packet is out of order.

   If a packet is in order then, it can be delivered immediately. If the
   packet is in order, then the expected sequence number MUST be set
   using the algorithm:
  
   expected_sequence_number := packet_sequence_number + 1 mod 2**16
   if (expected_sequence_number = 0) then expected_sequence_number:= 1;

   Packets which are received out of order MAY be dropped or reordered
   at the discretion of the receiver.

   A simple extension of the above processing algorithm can be used to
   detect lost packets.

   If a router PE2 does not support receive sequence number processing,
   then the sequence number field MAY be ignored.

This section is identical in the ethernet or atm draft, and should be 
identical in the frame-relay draft as well.
Also Stewart, Yakov Stein and I discussed the concerns raised at the 
last ITU  meeting , and concluded that this text is correct and needs no 
changes.

Thanks.
Luca

Luca

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 25 Nov 2003 14:45:37 -0500

Luca,

If you are changing the text related to sequence checks anyway, you may want to take the comment below into account.

Peter

> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]]
> Sent: Tuesday, November 25, 2003 12:53 PM
> To: [email-masked]
> Subject: [PWE3] ATM/Ethernet/Control drafts minor corrections
> 
> 
> WG members,
> 

There should be two different algorithms: one for the case in which misordered packets are dropped and one for the case in which reordering takes place.

The algorithm specified in the draft applies to the case in which packets are dropped. Stating at the end that out-of-order packets may be reordered doesn't make sense.

Look at the following case: suppose  the expected sequence number is 3 and a packet arrives with packet sequence number 4. According to your algorithm, the packet is in order and is delivered immediately and the expected sequence number becomes 5. Now suppose a packet with packet sequence number 3 arrives. This packet is out of order. However, it can not be reordered, because its successor has already been forwarded. It can only be dropped.

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

---

From: Luca Martini <[email-masked]>
Date: Tue, 25 Nov 2003 14:51:11 -0700

good point.

So this could be fixed in the following way:

to

If the packet is in order, then the expected sequence number MUST be set
using the algorithm:

after all it is implied that a packet should be delivered at some point.

This would give implementations the ability to reorder the packet if needed.

the other options are to remove the "packet can be reordered" text, or actually have 2 algorithms.
I think the above text should be sufficient for inter-operability.

Luca

---

From: [email-masked]
Date: Tue, 25 Nov 2003 22:22:22 -0000

Luca/Peter, I have some related questions that ought to be relevant to interworking....and, as an operator, I'd like to know what is being proposed here anyway:
-	At what level and over what 'period' of pkt loss and/or misordering, as determined from the sequence numbers, is the PW entity considered to have failed?
-	And at that point what consequent actions are taken?
-	What is the criteria in terms of good pkt reception, as determined from the sequence numbers, is the PW assumed to have come out of its failure state?

regards, Neil

> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Luca
> Martini
> Sent: 25 November 2003 21:51
> To: Busschbach, Peter B (Peter)
> Cc: [email-masked]; Yaakov Stein; Stewart Bryant
> Subject: Re: [PWE3] ATM/Ethernet/Control drafts minor corrections
> 
> 
> good point.
> 
> >If you are changing the text related to sequence checks 
> anyway, you may want to take the comment below into account.
> >
> >Peter
> >
> >  
> >
> >There should be two different algorithms: one for the case 
> in which misordered packets are dropped and one for the case 
> in which reordering takes place.
> >
> >The algorithm specified in the draft applies to the case in 
> which packets are dropped. Stating at the end that 
> out-of-order packets may be reordered doesn't make sense.
> >
> >Look at the following case: suppose  the expected sequence 
> number is 3 and a packet arrives with packet sequence number 
> 4. According to your algorithm, the packet is in order and is 
> delivered immediately and the expected sequence number 
> becomes 5. Now suppose a packet with packet sequence number 3 
> arrives. This packet is out of order. However, it can not be 
> reordered, because its successor has already been forwarded. 
> It can only be dropped.
> >
> >  
> >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 25 Nov 2003 18:04:14 -0500

Hi Luca,

If I had to implement a reordering algorithm, I would make a distinction between two cases:

- packet seq# = expected seq#
- packet seq# > expected seq#

In the second case, I would not increase the expected seq#, but just store the packet and set a flag to indicate that out-of-order packets are stored for transmission.

In other words, I would not follow the text that you suggest below.

However, I have not implemented a reordering algorithm and don't intend to do so. Is there any vendor who has? If we believe it is important to define exactly how reordering is done, I think we should start with existing implementations.

Peter

> Sent: Tuesday, November 25, 2003 4:51 PM

---

From: Luca Martini <[email-masked]>
Date: Tue, 25 Nov 2003 16:08:22 -0700

>-	At what level and over what 'period' of pkt loss and/or misordering, as determined from the sequence numbers, is the PW entity considered to have failed?
This is an implementation specific detail , not part of the protocol. 
You should probably ask your router vendors how they handle this 
situation. ;-)
I believe that the methods described in the VCCV draft are probably more 
appropriate to determine if there is packet loss on the PW path then 
using the sequence number. The sequence number is used to avoid 
delivering packets out of order.

>-	And at that point what consequent actions are taken?
this is again an implementation specific detail.

>-	What is the criteria in terms of good pkt reception, as determined from the sequence numbers, is the PW assumed to have come out of its failure state?
same as above.

Luca

>>>>    - otherwise if the packet sequence number < the 
>>>>        
>>>>
>>expected sequence
>>    
>>
>>>>  Packets which are received out of order MAY be dropped 
>>>>        
>>>>
>>or reordered
>>    
>>
>>>>    - otherwise if the packet sequence number < the 
>>>>        
>>>>
>>expected sequence
>>    
>>
>>>>  Packets which are received out of order MAY be dropped 
>>>>        
>>>>
>>or reordered
>>    
>>
>>>>  A simple extension of the above processing algorithm can 
>>>>        
>>>>
>>be used to
>>    
>>
>>>>  detect lost packets.
>>>>
>>>>This section is identical in the ethernet or atm draft, and 
>>>>        
>>>>
>>should be 
>>    
>>
>>>>Also Stewart, Yakov Stein and I discussed the concerns 
>>>>        
>>>>
>>raised at the 
>>    
>>

---

From: [email-masked]
Date: Tue, 25 Nov 2003 23:37:01 -0000

Thanks Luca.  Please see below.

regards, Neil

Luca Martini wrote 25 November 2003 23:08
>
> >-	At what level and over what 'period' of pkt loss and/or 
> misordering, as determined from the sequence numbers, is the 
> PW entity considered to have failed?
> >  
> >
NH=> This seems like a cop-out response to me.  I don't see why we can't have clarity on how the protocol handles this situation since as an operator:
(i) I want to be sure 2 different suppliers boxes interwork consistently and (ii) the behaviour seen by clients is consistent/known;
...and as a potential customer (ie if I leased such a PW service):
(iii) I would like to know what behaviour to expect.

> You should probably ask your router vendors how they handle this 
NH=> Ok, so I am asking you in your new job as you supply to BT....so I'd be grateful if you could please respond off-list and in private then.  Thanks.
<snipped to end>

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 26 Nov 2003 09:12:53 +0200

Luca and all,
I'd like to repeat my previous comment regarding lack of default mode 
(port with service-delimiting VLAN tags, port with VLAN tags that are not
service-delimiting, tagged)
in the Ethernet encapsulation 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.)

> Sent: Tuesday, November 25, 2003 7:53 PM
> To: [email-masked]