define a constant packet size in file transmission through the network

[MoeinClv]

Hi dear Cisco Experts

Can we define a specific packet size  for transferring through the network?

For Example; we want to send a text file of 150,000 bytes, Can we send it as packets of custom size (for example packets of 13840 bytes) ?!

[Giuseppe Larosa]

Hello Moein,

the packet size is negotiated by the two endpoints in TCP session setup.

A packet size of 13840 bytes is too big and would require fragmentation and would cause lower performance end devices should perform fragment re-assembly and would use buffer resources to store all fragments.

Routers in the path cannot know what is the size negotiated by the two endpoints.

Hope to help

Giuseppe

[MoeinClv]

Hi dear Giuseppe!
well, Can we configure router or switches to just accept packets of for example 1384 bytes (no to accept packets of 1385 or 1383 bytes)?
@Giuseppe Larosa

[Giuseppe Larosa]

Hello Moein,

as far as I know we can use a match size in a route-map used for PBR.

However, packets not matching PBR are usually routed by destination based routing.

To have packets with only a specific size to pass you should use the following:

An extended ACL defining the involved endpoints both directions may be useful like

access-list 112 permit ip host 10.10.11.23 host 10.10.22.55

access-list 112 pemit ip host 10.10.22.55 host 10.10.11.23

Your route-map shoud look like something like

route-map PBR-size permit 10

match address 112

match not length 1384

! following discard packets with size not expected between addresses permitted by ACL 112

! sending packets to null0 means silent drop

set interface null0

route-map PBR-size permit 20

match address 112

match length 1384

! we perform no action here

The route-map has to be applied on the interface receiving packets on the path.

This can be supported on routers and multilayer switches, but not on L2 only switches.

see following link

ttps://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/xe-16-5/iri-xe-16-5-book/iri-pbr.html

note: you need to verify with tests what length matches (L3 PDU size OR L3 PDU plus some L2 overhead ?)

The use of an extended ACL combined with the check on packet length is necessary to avoid to drop packets that need to be accepted and routed

Edit:

on carrier grade ASR 9000 support for checking packet length in QoS class-maps has been introduced in IOS XR 5.2

see following thread

https://community.cisco.com/t5/xr-os-and-platforms/asr-9000-acl-packet-length-match/td-p/2950932?dtid=osscdc000283

Here, the suggestions is to rate-limit instead of always dropping in a context of defense against DoS attacks.

Hope to help

Giuseppe

[MoeinClv]

so, can we determine a specific packet size? for example; can we send a text file of 141,200 bytes in 100 packets of 14,00 bytes and 1 packet of 1200 bytes? (I mean is it possible to send a file as fragments of custom packet size)
@Giuseppe Larosa

[Giuseppe Larosa · Accepted solution]

Hello Moein,

in a TCP transfer between two endpoints the MSS = Maximum Segment Size is negotiated at session setup.

Usually the MSS is equal to : IP MTU - IPv4 header - TCP header = 1500 -20 -20 = 1460 bytes.

So a file transfer of a text file of size 141200 bytes would use:

96 packets with MSS = 1460 bytes and a last packet of 1040 bytes at TCP level

at IP level we would have 96 packets of size 1500 and one packet of size 1080 bytes.

In order to force a MSS of 1400 the endpoints or the router interfaces facing the endpoints require specific configuration.

In order to use only packets of a fixed size a custom application would be needed on endpoints using some form of padding (adding binary 00) to make last packet size equal to all other packets.

Hope to help

Giuseppe

[MoeinClv]

You are really a professional expert and its proud of me to discuss with such a expert. Thanks a lot for your helpful commands.

"In order to use only packets of a fixed size a custom application would be needed on endpoints using some form of padding (adding binary 00) to make last packet size equal to all other packets"you said; Would you please help me about these specific configuration and custom applications more?! @Giuseppe Larosa

[Giuseppe Larosa]

Hello Moein,

I am not able to provide help in developing the custom application.

There are some points that I would like to point out:

you should use the lowest level libraries available for example C++ and libraries at low level interacting with TCP/IP.

However, in most cases for the layered approach the library you can use make an API call to operating system TCP/IP stack opening a so called socket and performing reads and writes on the socket handle (like it was a file handle).

The issues arises for the first packets used to set up the TCP session :

Sender A sends a packet with SYN TCP flag set to host B on a well known port representing a service.

The packet contains the initial sequence number ISN used by sender A for sending user data.

Host B answers with a packet with SYN TCP flag, ACK flag set with SenderA's ISN+1 in the ACK field and ISNb in the sequence number field

The host A answers with an ACK containing ISNb+1 in ACK value and TCP ACK flag set.

The issue here is that these first three packets do not carry user data and create the socket.

So we should be able to discriminate these initial packets from following packets.

In the case of Cisco routers it is not possible to match TCP flags directly but there is the keyword established that means SYN flag not set. So the extended ACL should be something like:

access-list 130 permit tcp host host-A host host-B established

access-list 130 permit tcp host host-B host host-A established

However, the third packet in the TCP three way handshake has the SYN flag unset and qualifies to match the above ACL.

Here it is the difficulty of this approach: even the lowest level library that you can find may use operating system API calls to create the socket and a socket handler is made available to your program after the three packets are exchanged.

If so the issue is how to allow the third packet to be transmitted even if its size cannot be adjusted to the desired size and it is already classified as TCP established.

So it is real a challenging task to make a program that implement the custom application.

You would need to find a customizable TCP/IP stack to use instead of standard calls to make the size of third packet the desired size.

For understanding all the details of the TCP protocol you can refer to two very famous books

TCP/IP illustrated Volume I  Stevens

"Internetworking with TCP/IP volume I" by Douglas Comer. This book explains all the details about TCP/IP and many details about different implementations.

see

https://doc.lagout.org/network/Internetworking%20with%20TCP_IP%20%20Vol%20I.pdf

As far as I know the first packet with user data should be packet  number 4.

Hope to help

Giuseppe

[Joseph W. Doherty]

I believe the answer is yes, although your application will likely need to access lower portions of the network stack to do so. IP supports packets up to 64 KB. However, as Giuseppe notes, large packets (actually any larger than MTU) will need to be fragmented, which has many negative issues. One of which is, if a packet fragment is lost, I recall the whole packet needs to be resent.

As to you later posted question, I recall (?) some devices support analysis of packet (frame?) size, and if so, then they should be able to drop sizes not desired.

BTW, why would you want to do either?

[MoeinClv]

Can you help me more in these 2 cases, Please?
@Joseph W. Doherty Checkout your inbox massages please