Subject: [Tsvwg] SCTP: Fast Recovery questions

From: mendes <[email-masked]>
Date: Mon, 02 Oct 2006 10:05:58 +0200

Hi list,

I have some general questions regarding the fast recovery mechanism. I
assume the following scenario:

We are in Fast Recovery phase (cumulative ack < fast recovery exit
point, a fast retransmit has been performed).

1.) When another fast retransmit event occurs, do we send another fast
retransmit (even though we are in fast recovery phase) or do we only mark
packets for retransmission?

2.) All packets that have been tagged for retransmission have been
retransmitted and cwnd allows more data to be sent. Do we send this data or do
we wait until fast recovery is over?

3.) Similar to question 2 but we do have retransmissions outstanding
that can not be retransmitted due to cwnd restrictions. Do we send new data
instead to use up the cwnd?

I couldn't find a clear answer to these questions in the RFCs. All comments
appreciated.

Regards

Hendrik

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Tue, 10 Oct 2006 16:32:14 +0200

Hi Paolo,  

>-----Original Message-----
>From: mendes [mailto:[email-masked]] 
>Sent: Monday, October 02, 2006 10:06 AM
>To: [email-masked]
>Subject: [Tsvwg] Comments on RU PDB draft
>
>Dear all,
>
>here are my major comments to the RU PDB draft.
>
>  It is not clear the relationship of the proposed mechanism 
>with a PDB, since the proposed RU PDB is not based on a new  
>behaviour (domain wide and node specific) to handle traffic. 
>It seems more as a policy mechanism which re-marks packet that 
>are overloading existing PDBs.

I think it can be considered as PHB. It describes the behaviour of a Diffserv domain seen by a node from outside this domain. It can be combined with existing PDBs or used independently of other PDBs. 

>Moreover, in DiffServ it is common to drop EF packets and 
>re-mark AF packets (to lower priority classes, such as BE) 
>that overload the defined profile for those classes. So, what 
>is the impact of this idea of re-marking non-compliant packets 
>to a local_DSCP which has the same PHB treatment as the 
>original PDB in the DiffServ operational model?

The main difference is that the forwarding behaviour of original_DSCP and the associated local_DSCP marked packets get the same forwarding behaviour. The local_DSCP packets can be used to inform e.g., diffserv aware IMS media gateway about the status of the resources available within the Diffserv domain, which can e.g. block original_DSCP traffic.

>  It is also not clear the motivation of this proposal in 
>relation to existing mechanisms that can detect congestion in 
>the network and so, allow the source of traffic to reduce rate 
>of the admission control in ingress point to be adjusted. 
>Moreover, the application of this congestion notification 
>mechanisms seems to require less changes to the DiffServ model 
>than the proposed RU PDB.

It can be used in combination with other application solutions, for example in combination with end-to-end ECN congestion control. The RU-PDB does not require changes to the Diffserv model, it uses Diffserv functions. The local_DSCPs can be experimental or local use DSCPs, which do not need to be standardized.

>
>Some parts of the draft require extra clarification, such as:
>- If the original_DSCP is remarked to a local_DSCP, the latter 
>one is remarked to what?

Remarked to an experimental or for local DSCP.

>- How do you implement the referred virtual queue?

It can be implemented using a Drop Tail physical queue and by maintaining information about the number of queued local_DSCP and original_DSCP marked packets. Note that in this case two virtual queues are provided, one for local_DSCP marked and another one for original_DSCP marked packets.

>- Since local_DSCP are re-marked pkts of the original_DSCP, 
>why should the former have less drop priority? Moreover, this 
>since a mechanism similar to the AF drop precedence.

Please note that the lower dropping rate of the local_DSCP marked packets is associated with the higher significance of these local_DSCP marked packets in relation to the resource unavailability notification procedure.

>-  it is said that this PDB can be applied in relationship to 
>multiple DiffServ domains. In is a strange sentence when 
>referred to a Per-Domain-Behaviour, which my definition is 
>applied only to one domain.

Maybe it is not clear, but we actually assume SLAs between multiple neighboring Diffserv domains and therefore, it is considered that there is trust relationship between these domains.

>Cheers
>Paulo