Subject: Unacceptable ACK in SYN_RCVD state handling

From: Murali Bashyam <[email-masked]>
Date: Fri, 05 Apr 2002 11:14:22 -0800

Hi

In SYN_RECEIVED state after sending a SYN-ACK to the peer, when TCP
receives a unacceptable ACK
i.e the ACK lies outside the receive window, it is supposed to drop the
incoming ACK and respond with a pure ACK as it should for any packet
that is completely outside the receive window. This is reqd as per RFC
793.

In BSD TCP code (FREEBSD/NETBSD) i notice that in SYN-RECEIVED state any

outgoing segment generated would carry the SYN bit as well as the ACK
bit set. So BSD code, when it responds with a ACK in the above scenario
also has the SYN bit set. Is this acceptable behaviour? Linux responds
with a pure ACK in this scenario.

Murali

---

From: Murali Bashyam <[email-masked]>
Date: Mon, 08 Apr 2002 14:38:06 -0700

---

From: Arun Prasad <[email-masked]>
Date: Tue, 09 Apr 2002 10:09:47 +0530

Hi all,
    Some doubts on the procedure followed for PMTU (Path mtu) discovery and
ECN method.....
    The doubt is not related to the procedure as such, but the relation between the
two procedures stated above......
Tcp and Sctp uses ICMP message to handle the PMTU discovery procedure....
ie., the intermediate router will send an ICMP messge of "Message too Long"
to the end point sending the data packet of size greater than the MTU size of some
intermediate path to the destination.....

For ECN, the intermediate router should set the appropriate bits in the IP header
(if it supports ECN ....) whenever there is congestion and risk of packet drops
is high....... The endpoints then correct their Congestion window accordingly and
help in reducing the Congestion in the intermediate router.....

Why, we adopt two different methods to carry out similar (in the sense, both are
related to the Intermediate routers....)?????
    Why cant we generalise this stuff.... ie.,  the need here is some way to
communicate between the intermediate router and the endpoint.... Not sure
which of the two ways is advantageous, but cant we use the same method for
both..... ie.,
As for the PMTU discovery, the intermediate router can send an ICMP message
to the endpoint carrying a message "CONGESTION", by receiving this the
endpoint will do all appropriate actions as it does when it receives the packet set
with ECN-ECHO flag (as in present ECN procedure...)

or vice versa ( ie., adopt the method followed by ECN  for PMTU discovery aslo,
that might be slighly tough, considering the Backward compatibility....)

    What we can achieve by this is the simplicity  in the router implementation,
which doesnt need to do different procedure for different features of the Transport
layer..... and by maintaining this uniformity, the future extentions which demands a
similar requirement can use the same way......

I could have missed some points....

Any comments on this????

Thanks
-arun
--
****************************************************************
V.Arun Prasad
HCL Technologies Ltd.
51, Jawaharlal Nehru Road,
Ekkattuthangal,
Guindy Industrial Estate,
Chennai - 600097.

Contact # : 9144 - 2334174
            9144 - 2334181
            extn : 233
****************************************************************

---

From: Jacob Heitz <[email-masked]>
Date: Mon, 08 Apr 2002 23:09:56 -0700

One reason: sending extra packets in the face
of congestion will worsen the congestion.
Congestion collapse could be a very serious possible
consequence of sending extra packets.
Notice the ECN does not go towards the sender,
but in the other direction. I think the intention
is to have the upper layer (transport) in the
receiver withhold acknowledgements to cause the
sender to back off. I'm making this up, so please
correct me if I'm wrong.

PMTU discovery does not face this problem. It's ok to send
an extra packet back to the sender in this case.

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

-- 
// Jacob Heitz. Tel:510-747-2917

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Tue, 09 Apr 2002 04:01:26 -0500

Jacob's comments are roughly correct.  Bits in the IP header are very
precious so we expend them only for a REALLY good reason, e.g. ECN.

> sender to back off. I'm making this up, so please

You are correct that the transport layer is supposed to handle the
Congestion Experienced (CE) bits in the IP header.  In the case of
both SCTP and TCP the reaction is to include a transport-specific
congestion notification in the next ACK.  This allows the sending side
to back off just like normal congestion detection, but without losing
a packet.

> an extra packet back to the sender in this case.

I.e. there is no need to spend IP header bits on this function.

---

From: Arun Prasad <[email-masked]>
Date: Tue, 09 Apr 2002 15:27:22 +0530

hi jacob,

> consequence of sending extra packets.

         I couldnt get the point of, sending extra packets during congestion.....
Say if a Router decides that there will be congestion ( its not in congestion now...)
then it decides to set the ECN bit in the IP header of certain packets in the Queue...
These packets should reach the receiver endpoint.... then the receiver will
send a ACK to the sender to indicate there is a congestion..... Doesnt this too
long a process.... ie., anyway a SACK is to be sent from the Receiver to the
sender....  In that case why not an ICMP packet from the router to the sender???

And also, since the extra packets are going to flow in the opposite direction
of the actual congestion, I couldnt see any harm .... (I know this might be a
wrong statemnent.... but I dont have the right justification...)

Atleast in Source Quenching method, the flooding of Data by the Sender can be
controlled fast than the current ECN method...right!!

> sender to back off. I'm making this up, so please

        Why at all a receiver bother about the Congetion....  I see no reasons for the
receiver to know about the congestion in the path.... because he cant do anything
about that...
And also by doing this by Source Quenching method.... its not mandatory that
both the source and destination Transport layers support the ECN capability..
If only sender is supporting, its more than enough... and there will be no necessity
to negotiate the support of this feature, end to end....
Router  also doesnt bother  whether an Endpoint is supporting  ECN or not...
he can just send an ICMP message to the sender, whether he supports ECN or not...
(slightly costly operation but thought its ok...)

Thanks
-arun

---

From: Jacob Heitz <[email-masked]>
Date: Tue, 09 Apr 2002 03:29:25 -0700

First of all, I gave a reason why it is so.
If you think another way is better,
that's nice, but you won't change anything.

Source quenching was always controversial.
It is considered higher impact, because it adds
an extra packet to the network. Setting a CE
bit adds nothing that was not there before anyway,
so is considered to be safer, or lower impact.

Yes, it's slower than having the congested router
send an ICMP.

The end receiver sends an ACK anyway. Let it modify
or withhold that ACK. This is what the receiver can
do. It would send the ACK anyway, thus nothing
extra is added to the network.

But consider these points:

A network is made of different makes/models of routers.
A router may consider itself congested in all
directions at once when it runs low on buffer memory.
Then it may send ICMPs every which way.

If a path is congested at many routers, each may send
an ICMP in the reverse direction, resulting in a
multitude of ICMPs reaching the sender.

When congestion collapse looms, safety first is the
golden rule: add nothing more that was not already
there anyway.

---

From: Arun Prasad <[email-masked]>
Date: Tue, 09 Apr 2002 16:48:23 +0530

hi jacob,

> that's nice, but you won't change anything.

    thats slightly harsh.....

> multitude of ICMPs reaching the sender.

    Ya, I got the point.... The above point really justifies the reason of not
selecting Source Quenching for ECN..... ( That may be obvious, but I missed
it....).. Thanks for this...

Thanks
-arun

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 09 Apr 2002 12:08:52 -0500

[I promise not to get sucked into this again, but a few clarifications are
in order.]

> so is considered to be safer, or lower impact.

...unless you also consider the TCP retransmissions to be expensive.

> Then it may send ICMPs every which way.

Is it going to start dropping packets anyway?

> multitude of ICMPs reaching the sender.

Good point.

> golden rule: add nothing more that was not already

On half-duplex links, that is a good idea.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Srivathsa <[email-masked]>
Date: Tue, 09 Apr 2002 17:08:42 -0400

> related to the Intermediate routers....)?????

Arun,
   I dont really see how the 2 situations are similar.
In the PMTU case,  the network is in normal state.

In the ECN case, there is a congestion at the router. The router cant
afford to pump more packets into the network.  In the earlier internet,
the source quench mechanism was used to combat congestion  (i.e router
sends an ICMP to the source).  In a quick evolution, routers started
using a packet-drop mechanism to combat congestion (It didnt make sense
to pump more packets into a congested network).  Now, ECN is being
recommended to combat congestion VERY EARLY. 
  i.e PMTU-like-mechanism cant be used for ECN.

> that might be slighly tough, considering the Backward compatibility....)

You cant use a ECN-like-mechanism for PMTU discovery.   As soon as an
intermediate router discovers that the packet (with DontFragment bit set
) is too large for one of its outbound interfaces,   it will have to
discard the packet.  I.e it cant relay the packet to the
destination.      In ECN scenario,  packet can still be relayed further.

-Srivathsa

---

From: Arun Prasad <[email-masked]>
Date: Wed, 10 Apr 2002 09:53:51 +0530

> destination.      In ECN scenario,  packet can still be relayed further.

            Ya, I agree that......  But the  method by which PMTU discovery is done
can be changed to avoid packet drops (if dropping a packet is costly... I think
yes, because it triggers Retransmissions....). We might rethink about implementing PMTU
discovery like the ECN like mechanism, with this new proposal..... The idea is

there should be  someother bit like the DF bit, say IF bit (Inform on Fragmentation) in the
IP header..... This IF bit will be set by the Transport layers if it is planning to do the PMTU
discovery.....  The router upon receiving a packet of size greater than the MTU size of the
Egress interface and the IF bit is set in the IP header... then IP layer there will go ahead
 fragmenting the packet and sending it to the destination..., but also send an ICMP
"Message too Long" message to the Sender.....  The router also sets the DF bit, and
unsets the IF bit in the IP header of the fragment packets (which ensure no more
fragmentation is done on the packet....)  ..................The sender upon receiving the ICMP
packet will just update his PMTU... Thus there is no Packet drops... so the procedure of
PMTU discovery will not  trigger any Retransmissions.... (which is expensive, because
the transport layer shrinks the Congestion window if it senses that a packe is dropped...)

Not sure whether this is already discussed or proposed etc...

Thanks
-arun

---

From: mbashyam <[email-masked]>
Date: Tue, 09 Apr 2002 22:53:00 -0700

> the transport layer shrinks the Congestion window if it senses that a packe is dropped...)

I dont understand, PMTU discovery requires that TCP go into a retransmission of all its
unacknowledged packets if there is a change in MSS.

Also in ur scheme by forwarding the fragments with DF bit on won't u  be triggering
drops in a downstream router with a smaller next hop MTU than the just announced
PMTU ?

Murali

---

From: Marcel Waldvogel <[email-masked]>
Date: Wed, 10 Apr 2002 10:04:42 +0200

Arun Prasad wrote:
 > can be changed to avoid packet drops (if dropping a packet is
 > costly... I think yes, because it triggers Retransmissions....). We
 > might rethink about implementing PMTU discovery like the ECN like
 > mechanism, with this new proposal..... The idea is there should be
 > someother bit like the DF bit, say IF bit (Inform on Fragmentation) in
 > the IP header..... This IF bit will be set by the Transport layers if
 > it is planning to do the PMTU discovery..... The router upon receiving
 > a packet of size greater than the MTU size of the Egress interface and
 > the IF bit is set in the IP header... then IP layer there will go
 > ahead fragmenting the packet and sending it to the destination..., but
 > also send an ICMP "Message too Long" message to the Sender..... The
 > router also sets the DF bit, and unsets the IF bit in the IP header of
 > the fragment packets (which ensure no more fragmentation is done on
 > the packet....) ..................The sender upon receiving the ICMP
 > packet will just update his PMTU... Thus there is no Packet drops...
 > so the procedure of PMTU discovery will not trigger any
 > Retransmissions.... (which is expensive, because the transport layer
 > shrinks the Congestion window if it senses that a packe is dropped...)

I like the idea of an "Inform-on-Fragmentation" bit, as this would get
the PMTU right within one RTT *and* not require any retransmits. I do
not agree with your DF/IF interaction, instead I propose my own rules
(downward compatible, single RTT, no retransmit (exception below)):

* IF overrides DF.
  Any IF-capable router will ignore DF on packets that have IF set. IF
  is more powerful than DF, but DF will be needed during a transition
  period.
* Routers do not modify the IF/DF bits.
  When the sender sets IF and DF (probably the common case), there is
  no need for that.
* Routers send back an "ICMP Fragmentation needed," indicating it was
  due to IF.
  This is preferably done only on the first fragment (i.e., offset=0).
* IF-capable routers that don't want to/can't fully perform
  fragmentation (e.g., IPv6) shorten the packet into the first
  fragment.
  The "Fragmentation needed" message then contains the information
  that the packet needs to be resent.

-Marcel

---

From: Kostas Pentikousis <[email-masked]>
Date: Tue, 16 Apr 2002 16:28:24 -0400 (EDT)

On Tue, 9 Apr 2002, Jacob Heitz wrote:

[...]
  | Source quenching was always controversial.
  | It is considered higher impact, because it adds
  | an extra packet to the network. Setting a CE
  | bit adds nothing that was not there before anyway,
  | so is considered to be safer, or lower impact.
  |
  | Yes, it's slower than having the congested router
  | send an ICMP.

I'm not sure that's really true. In fact, I've heard several times that Source
Quench (SQ) via ICMP is more expensive for current generation routers than
setting a bit. I remember reading that any packets needing "special" treatment
are placed in a separate (lower priority) queue and are dealt with when the
router load drops (a bit). Setting a bit is not considered "special" treatment
but creating a packet (setting source and destination addresses, etc.) is. If
this is true, and ECN was spec'ed so that the router would send an SQ ICMP
packet back to the sender instead of setting a bit (RFC 3168), then in most
cases the congestion notification would actually arrive later than an RTT.

Just my $0.02,

Kostas
______________________________________________________________________
Kostas Pentikousis @ CS Stony Brook @ http://www.cs.sunysb.edu/~kostas