Subject: [Tsvwg] [Fwd: Re: draft quick start comments: part 1 of 2]

From: Erblichs <[email-masked]>
Date: Thu, 16 Mar 2006 14:42:39 -0800

Mark Allman,

I have re-subscribed myself for this discussion and because
I have a considerable amount of TCP work on my plate.

Mitchell Erblich

-------- Original Message --------
Subject: Re: draft quick start comments part 1 of 2
Date: Thu, 16 Mar 2006 14:21:29 -0800
From: Erblichs <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
References: <[email-masked]>

Mark Allman,

	I guess I was too terse. Here comes the verbose inline..

	Mitchell Erblich
	--------------------

Mark Allman wrote:
> 
> Chopped the list from the CC line ... Am happy to take this to the list,
> but this note is mostly about clarifying the questions.
> 
> >       3) I see no mention of single hop connections between
> >          routing protocol's like BGP,LDP etc neighbors, peers,
> >          that are 1 hop distances and where a number of
> >          multihop issues are removed AND depend on TCP.
> 
> What are you asking us to say here?  Isn't the single hop case just a
> subset of the bunch-of-hops case?

	No. It is a special case that removes a number of issues and
	introduces a number of other issues.

	   A single hop case an example of a special case. Here are
	   a few of the items that could be explored.

	    * In the single hop case, the src is aware of any traffic
	      that is generated by itself. 

	     * In the single hop case, if the dst B previously sent
	       sent a QS req to A, then A can be assured that B is
	       QS aware.

	     * The dst can successfully modifiy both TTLs in a
	       successful manner. Is this a security issue?
	       
	     * In the single hop issues, transiting slower links
	       before the dst is not an issue, thus SHOULD QS bit/sec request
	       ALWAYS be accepted for P2P connections or direct connections, 
	       if the request is at the speed of the link and the dst 
	       supports QS (this is not a shared link)?,
	
		The only thing QS gives us is that the dst can and will
		allocate the resources for its recv window.

	    * It does not have to be concerned about "Multiple paths"
	      specified in 9.2. where:
		"One limitation of Quick-Start is that it presumes that
	         the data packets of a connection will follow the same
		 path ...

	     * With BGP/LDP where the src / dst pair are immediate nbrs/peers
	       actually many sections with the word "routers" seems to be
	       inaccurate. I think the draft RFC assumes that the src / dst
	       are end-systems that need routers in a normal TCP connection.
	       Example: "ABSTRACT: in cooperation with routers."
	       is technically invalid.

	      - Thus here is a special case where the src/dsts are routers.
	
	--->  Added for forward..Is their a need for the C. Router Algorithm
	      if src/dst are routers and src/dst do NOT use a shared link?????

	     * LDP/BGP both rely on TCP and where at least a subset of
	       neighbors / peers are immediate nbrs/peers. BGP allows for
	       the negotiation of a number of parameters and LDP extends
               the TCP establishment for sessions with a state machine.
	       Has their been any testing with these other protocols and
	       are known issues with QS in these environments.

	     * I thought alot of MPLS clouds are treated as a single
	       hop and have no idea how the internal MPLS routers will
	       verify any Router Bandwidth calcs. Maybe only the ingress
	       end egress routers need to do the calcs? But I am still
	       think their must be TE issues..

	      etc...
	   
> 
> >       4) I did not see until almost halfway into the doc that
> >          multihop/multipath issues are even mentioned. FYI:
> >          in NON strict/loose explicit route environments like
> >          TCP/IP that any later pkt/seg will traverse the same
> >          path as a previous seg/pkt. Thus, reordering and load-
> >          balancing may be done by a router on the same flow or
> >          two flows with the same src/dst?
> 
> I cannot parse this question.

	     * One of the most common issue with a TCP/IP environments is
	     that there is a presumption that data packets will follow
	     the same path. This shows up in your document at section
	     9.2 under the "Multiple path:" section which is halfway
	     into the document. I would have expected these statements
	     to be addressed in 1. Introduction.

	     * TCP/IP does not support any strict explicit route
	      paths for connections.

	     * TCP/IP does not support any loose routing paths.

	     * TCP/IP does not pinn any flow to a single path.

	     * Because of the above 3 bullets, where alternate paths exist, 
	      it is POSSIBLE based on the path metric that even when a
	      full path supports QS aware entities.
		- that the QS aware path won't be used.
		- that the QS path will be used in connection establishment,
		  and then switched to a different path,
		- will be load balanced between the two paths,

	---->  * Thus, IMO, if a router if recieving a QS request and has
	       alternate paths where the next hop could be a QS aware
	       entity, that path should be preferred for the flow and
	       if possible pinned to that path.

> 
> >       5) I think their are some implicit references to items
> >          that are identified as "cross-traffic". In my experience
> >          if cross-traffic are UDP based then significant mention
> >          needs to be made of them. FYI: UDP is a non self
> >          regulated flow that is either application limited,
> >          controlled by queue drops, etc.
> 
> I don't follow what you want us to do here.  For sure, competing against
> UDP is different from competing against TCP.  But, the document is
> pretty generic on this point because there is no good way to know what a
> flow is competing with.
		
		yes, however...
		- You identify "cross-traffic" but make no mention of what
	          it is or could be,
		  a) Is it undocumented/unrequested non QS flows?
  		  b) are they older QS flows that are no longer tracked because
		     1 RTT has been sent and recived?
		  c) are they flows entering one slower bandwidth router interface
	             and exiting a faster interface,
		  d) etc..
		- UDP is not window / ack flow controlled so no congestion avoidance
	          method other than drop is available,
		- C. Possible Router Algorithm seems to ignore the unknown/
	             uncontrolled flows. It is hidden in the available
		     bandwidth calc.
	         - The above algorithm assumes that a previous bandwidth used
		   at a preceeding interval is identifies the expected flow during
	           the next interval. I disagree. WHY?
			- some non QS TCP flows are in Quick-start and are
	                  doubling their inflight segments per RTT.
			- some UDP flows will be sent at application controlled
			  wirespeed limit
		        - some flows have been idle and will  resume close
	                  to their previous flow capacity
			- some flows will go idle.
			- Thus the accuracy is partially dependent on the number
	                  of flows and the variability of each flow.
			- some link medias are bursty in nature and may avg
	                  at a value that is no way representive of their
			  bandwidths at different time intervals..
		 - 8.2 Deciding the Permitted Rate Request of a Router
		    Potential bandwidth consists of requsted and non
	            requested flows. I see no mention of non requested
	            flows from TCP and/or UDP 
	---->	  - There also needs "fluff" for older QS flows that are
	            still incrementing the number of inflight segments.

> 
> >       6) I was confused if a router wanted to accept the request.
> >          How does/SHOULD the router differentiate two flows
> >          from the same src? Based on src/dst? Additional factors?
> >          This is an issue if a router wishes to police the
> >          connection? It also identifies that two requests from
> >          the same router / may collide with each other. Should
> >          their by some tag/ID with each request?
> >
> >          8.2 Deciding the Permitted rate Request at a Router
> >           ----------
> >          UDP pkt flow need to be considered by routers when
> >          they are to determine whether to accept QS requests.
> 
> The router doesn't have to differentiate flows at all.  I.e., the router
> is not required to keep per-flow state.  If the router wants to police
> later then it would store per-flow information keyed on the five tuple,
> I would guess (IP: src addr, dst addr, protocol; TCP: sport, dport).
> 
> As for considering UDP .... The router needs to consider the aggregate
> level of load, not particular kinds of traffic.

	     You mention polciing in the document, however that almost
	     seems to be treated as a after thought as to whether it
	     is feasible on a wirespeed packet basis.

	     For a router to support C. Possible Router Algorithm
	     * a single src could request a number of QS requests,
	     * to support a fairness policy, shouldn't the QS requests
	       have state information as to your above tuple information?
	     * The MPLS / LDP / etc are moving away from inspecting the
	       TCP header where the QS seems to request it?????
	     * Do you expect a MPLS Cloud internal routers be QS aware?
	     * Do we expect them to perform the desired normal TTL mods?
	     * If the internal MPLS routers ignore the normal TTL
	       decrement, how do we expect them to support the bandwidth
	       calcs in
             * And sorry state needs to be kept so the older QS flows as
	       they age out of QS are tracked that they are still using
	       bandwidth
	     
> 
> >       7) Should this functionality support path vect to determine
> >          what the path was taken?
> 
> I don't follow this.  Why do we want to know the path taken?  And, who
> would need/want to know?
> 

		this is answered in my #4 responses.

> >       8) In a normal slow-start reducing the number of acks by a recvr
> >          because segments are spaced to close together is suspended.
> >          Did i miss and wouldn't QS want to follow the same functionality
> >          until 1 full set of pkts have been ack'ed? Should the recv'r
> >          do it on a byte count, pkt count, or a RTT timer?
> 
> I don't follow this.  I think we have different models of how a receiver
> sends ACKs.  The standards call for receivers to send an ACK for every
> second segment that arrives (RFC 2581).  We do not change this at all.
> So, I don't follow your question.
> 
		woooooooow, check with your people
		The common consensus is that in slow-start a single
		ack per segment is done to allow for lost acks and
		to decrease the time until ss threshold is reached.

		thus the delayed ack is suspended during slow-start.

		-----> Thus, if ssthresh is reached via QS, then delayed
		acks can resume, else they should be suspended until
		reached.

http://www.ssfnet.org/Exchange/tcp/test/f3.html
Note:Test Description:
This test shows how TCP with the delayed ACK property cannot get three
duplicate ACKs and has to wait for the retransmission timeout when a
packet is lost (generic Tahoe with delayed ack). Expected output:

    * For the link between 5(0) and 0(1)
          o the first packet (SYN+ACK) had been dropped at server (can't
be dumped at router), timeout happened for both sides. The SYN+ACK was
retransmitted, the congestion window is set to 1 packet. The ssthresh is
set to 2 packets (minimum of ssthresh value).
          o When the congestion window reaches ssthresh, congestion
avoidance is performed.
          o When the congestion window reaches 3 packets, 1 packet is
dropped because of the drop-tail queue.
          o Because the number of duplicate ACKs is always less than 3,
no fast retransmission happens. The timeout is triggered.
    * For the link between 6(0) and 0(2)
          o When congestion window reaches 3 packets, 1 packet is
dropped. Without knowing this, cwnd reaches 4 packets at the time next
ACK is received. One more packet is dropped.
          o Because the number of duplicate ACKs is always less than 3,
no fast retransmission happens. The timeout is triggered. The ssthresh
is set to 2 packets (half of min(cwnd, rwnd))
          o When the congestion window reaches ssthresh, congestion
avoidance is performed.
          o When the congestion window reaches 3 packets, 1 packet is
dropped because of the drop-tail queue.
          o Because the number of duplicate ACKs is always less than 3,
no fast retransmission happens. The timeout is triggered.

	Mitchell Erblich
	------------------

> allman
> 
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

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